You don't have permission to access /somefile.php on this server

[underg12]

Hi All,
My site on the Free Hosting service may have triggered one of the new mod security rules for Apache mentioned in the x10hosting Status Blog posted around a month ago ( http://status.x10hosting.com/ ): "The mod security rules should be showing a 403 if you inadvertently trigger a rule..."

The site URL is http://renegadekaraoke.x10host.com , and all of its scripts are custom HTML, PHP and some JavaScript libraries. While accessing certain PHP links which Registered Users can click, the user is redirected to a blank page that says: "You don't have permission to access /somefile.php on this server".

I've done some reading and I came across two other threads (http://community.x10hosting.com/threads/mod_security-causing-permission-error.195616/#post-938222 and http://community.x10hosting.com/thr...on-this-server-additionally-error-404.195774/ ) which both describe situations analogous to mine. I believe that the presence of many links generated in a page may trigger the security measures, since spam and botnets do mostly contain links to malware. I realize that the changes to the security measures are absolutely necessary, but it just so happens that my own site would generate links because of how its principal page is constructed. My site for the moment is not enabled for commenting and does not have a forum, and in no way do any of the links in its pages make it possible to lure users to click on them and be redirected to spam or malware.

The same Status Blog also said that I may "report to the forums just in case" I might be affected by the security measures, and so here it is.

I would greatly appreciate any assistance. Thank you x10host for having an excellent Free Hosting service!

Cheers

 

[underg12]

Just checking in to see (after some time) if there would be anybody here who may be able to resolve my query. Hope it's not too bothersome!

 

[Skizzerz]

Hello!

Unfortunately, even staff can't really assist you much without knowing which file(s) in particular are causing this error. If you could post a full path or link to an example file, that would be greatly appreciated (even if we can't access that page due to needing a login, we could check it out on the backend to see if there's anything funky with it).

 

[underg12]

Hi! Thanks for replying.

As requested, here is the link to one of the webpages that throw a "403 Forbidden" error when a user clicks on the "Submit" button of an "edit video details" form: http://renegadekaraoke.x10host.com/update_video.php .
The link above points to the file, but in actual practice, there'll be a query string after the last character, for example: http://renegadekaraoke.x10host.com/update_video.php?video_id=bdSMwIHUSXc .
The "edit video details" form submits to its own PHP file/webpage; it's kind of a pretty simple framework, really, no bells and whistles like a third-party CMS.
The "update_video.php" link problem has been occurring for quite a while now.

I also have a clickable link in the front page for logged in users to add new videos, and the URL is (rather unremarkably) http://renegadekaraoke.x10host.com/add_video.php . This PHP page also has a form that submits to itself. It used to work pretty well; that is, once the required fields in the form are correctly filled and verified, then a new entry is inserted into the MySQL database table. It has so far worked more than 320 times, I think. Then afterwards, it suddenly began throwing a "403 Forbidden" error, too.

So now, the Registered User has no access to both "update_video.php" and "add_video.php".

I'm kind of thinking that the presence of many iframes may have triggered some security measures?


I would greatly appreciate any help on this matter. Cheers!

 

[caftpx10]

Mod_security can get triggered by the usage of iframes, as far as I'm aware of. However, I'm not sure if it disallows iframes in general or a suspicious source set in one.

You've said that this worked (around) 320 times. When was this? Did you try this all in one day? What are the iframes for? Can the iframe source URI get modified from user input (POST, GET)? If so then is there any users inputting a URL involved?

 

[underg12]

Mod_security can get triggered by the usage of iframes, as far as I'm aware of. However, I'm not sure if it disallows iframes in general or a suspicious source set in one.
You've said that this worked (around) 320 times. When was this?

A registered user can add new entries into the database using a form in the "add_video.php" page. It's still a project in development; actually it's a demo of sorts. So I've been adding the entries myself. And so, I was able to add around 320 items using the HTML/PHP form.

When was this? Did you try this all in one day?

No, I was able to add up to a total of around 320 entries in a span of maybe three or four weeks. And then, the "add_video.php" page just suddenly threw a 403 Forbidden error. The page, and the ability for a Registered User to append entries into the database, did work for a few weeks.

What are the iframes for?

The website uses YouTube Iframe API in its index page. It's just one iframe, actually, except the source gets changed by the API depending on the click of the user on the navigation/control parts of the page. I'm quite sure there would be many here who would be aware that the YouTube Iframe API allows for dynamic iframe sources depending on the custom JavaScript coded into a page. The single iframe is used for displaying the YouTube video that a visitor to the site would want to watch.

Can the iframe source URI get modified from user input (POST, GET)? If so then is there any users inputting a URL involved?

Umm, yes, the Registered User is authorized to add or modify the iframe source URI with the forms in the "add_video.php" or "update_video.php" pages, respectively. It's like, since the YouTube Iframe API is doing the heavy work, the Registered User only has to insert text information into the form. The URI information along with the rest of the POST information is appended to and stored in the database, and then the PHP/JavaScript gets the data from the database entries and passes it to the YouTube Iframe API so the API can parse the information and subsequently load the required video into the iframe.

A visitor to the website, if not logged in (since visiting the website does not necessarily require the visitor to log in as a Registered User), would have no capability of editing the URI information contained in the database entries, or add new entries to the database. However, a visitor can "change" the source URI of the iframe because of the controls afforded by the index page navigation.

It's really just a simple type of CMS. At least I think it is, because the script is just...well, tiny compared to a full-blown PHP forum.

 

[caftpx10]

As this seemed to have stopped working recently, there's a possibility of mod_security having a rule update not too long ago. Some of the rules set makes certain sites nonfunctional (parts or it). Like for example, sites which allows users to post links. I know that the 403 comes along when there's user input that holds a URL because of a vulnerability that would be too long to explain but very logical. It's irreverent to this. Lol.

Does the users who are not logged in have this issue as well?

 

[underg12]

As this seemed to have stopped working recently, there's a possibility of mod_security having a rule update not too long ago. Some of the rules set makes certain sites nonfunctional (parts or it). Like for example, sites which allows users to post links. I know that the 403 comes along when there's user input that holds a URL because of a vulnerability that would be too long to explain but very logical. It's irreverent to this. Lol.

Does the users who are not logged in have this issue as well?

As far as I've been able to gather, the visitors who are not logged in have had no problem in changing the content of the iframe embedded in the index page. It's the logged in Registered Users who would have difficulties in using the "add_video.php" and "update_video.php" forms, because they can't insert entries or update/modify entries in the database. Strangely enough, deleting entries in the database seems to work smoothly.

I can't really see any possibility of making a workaround as of yet. Modifying the PHP code wouldn't essentially change the mechanism of the INSERT and UPDATE MySQL API commands. Like I said, it's really just simple code: bare-bones, maybe even skeletal, to tell the truth. I mean, even the equivalent of a first-grader in PHP could do this. Even the iframe "link" isn't strictly a URL link in the classic sense, since the Registered Users don't actually need to type any URL links in any of the forms. It's the YouTube Iframe API that handles the processing of the links to the YouTube videos. An astute user could try putting explicit URL links into the database but I think it wouldn't work, unless someone intentionally, maliciously hacked the PHP to get into the MySQL. And if that happens, then I'd have to step in myself because the very intention of the site would not be compatible with explicit links. Let them hackers watch out, grrrr

Anyway, I'm just seeking a little help. In no way am I saying that the mod_security measures are a bad idea.

 

[underg12]

However, there is a part of the script that would explicitly create URL links pointing to the YouTube thumbnails for the videos. That part of the script ( I think its JavaScript ) may be to blame. For every entry in the HTML table, there would be a part where the YouTube videoid (which is I think an 11-character code) is prepended with the standard YouTube URL pointing to the location of the thumbnail in their systems. This mechanism is not strictly controlled by any user input, it's just part of the automated process of assembling the HTML table. Could that be what's triggering the security measures?

 

[underg12]

it's this:

var videoid = $(videoidnode).html();

$(videoidnode).html('<img src="https://i3.ytimg.com/vi/' + videoid + '/default.jpg" alt="' + songtitle + ' thumbnail" width="120px" height="90px" longdesc="Thumbnail for the Youtube karaoke video of ' + songtitle + '" />');

Could explicitly created URL's like this, which aren't necessarily inputted by the user/s but part of the automation, be triggering security measures?

 

[underg12]

No, scratch my idea below. The img src attribute is not strictly a hyperlink, anyway, or so I believe.

it's this:

var videoid = $(videoidnode).html();

$(videoidnode).html('<img src="https://i3.ytimg.com/vi/' + videoid + '/default.jpg" alt="' + songtitle + ' thumbnail" width="120px" height="90px" longdesc="Thumbnail for the Youtube karaoke video of ' + songtitle + '" />');

Could explicitly created URL's like this, which aren't necessarily inputted by the user/s but part of the automation, be triggering security measures?