0

I have my header, footer, and other php files which process ajax requests in the /include/ folder.

For a static website, is used to set the nginx default file to

location ^~ /include/ { deny all; }

And when someone went to www.mysite.com/include/header.php it returned a 403 Forbidden

but now, since I use jquery ajax calls to files inside the /include/ folder, if I set this =>

location ^~ /include/ { deny all; }, no ajax stuff like saving or reporting works.

is there a way in which I could deny access to the files inside the /include/ folder to everyone else but make it accessible only for the webroot files?

I tried these:

location ^~ /include/ { allow 127.0.0.1; deny all; } but that doesn't work.

location ^~ /include/ { allow <my server's ip>; deny all; } but that doesn't work.

I have altered the ssh port from 22 to say, 123; should I type in:

location ^~ /include/ { allow 127.0.0.1:123; deny all; } instead?


Referred a tutorial to stop hotlinking as well from : http://www.nginxtips.com/how-to-stop-image-hotlinking-on-nginx/

According to that: I tried,

location ~ .(gif|png|jpe?g)$ {
     valid_referers none blocked mysite.com *.mysite.com;
     if ($invalid_referer) {
     return   403;
    }
}

to prevent hotlinking of images (did not work, I guess.) and

location /include/ {
     valid_referers none blocked mysite.com *.mysite.com;
     if ($invalid_referer) {
     return   403;
    }
}

to prevent access to the /include/ folder.

none of them worked, and yes, I replaced mysite to my website's real name in there

I also tried doing this:

 location ^~ /include/ {
         valid_referers none blocked mysite.com *.mysite.com;
         if ($invalid_referer) {
         return   403;
        }
    }

but, adding ^~ resulted in the page @ www.mysite.com/include/header.php 'header.php' in this case, being downloded; when visiting it in the browser.

I'm not using any CMS's, just plain php files used with css & js, incl that of bootstap's. (nginx 1.4.6, mysql, php5-fpm stack)

Any suggestions are much appreciated.

3
  • The server isn't the one making the AJAX calls, but rather the client's browser, so only allowing your server access to that folder won't work the way you expect it to. My suggestion would be to move all files called via AJAX into a separate folder and leave what you have for the include folder. As an alternative, you could possibly rewrite the AJAX requests.
    – GregL
    Oct 6, 2015 at 14:38
  • Yikes, that makes sense.
    – Aj334
    Oct 6, 2015 at 15:44
  • I just posted it as an answer, if you feel it warrants it, give it a checkmark.
    – GregL
    Oct 6, 2015 at 15:57

2 Answers 2

0

The server isn't the one making the AJAX calls, but rather the client's browser, so only allowing your server access to that folder won't do what you expect it to.

My suggestion would be to move all files called via AJAX into a separate folder (/ajax maybe) and leave what you have configured for the include folder.

In theory the files inside /include shouldn't ever be directly called by a browser, but are likely to be included (imagine that!) by your scripting language. That's why the AJAX-requested files should likely go in their own folder.

As an alternative, you could possibly rewrite the AJAX requests to the /include folder, but I'm not sure if the deny will apply in such cases.

1
  • Thanks man. I'll go with this until I find a better solution.
    – Aj334
    Oct 7, 2015 at 7:13
0

You can allow access based on the X-Requested-With: XMLHttpRequest header that most Javascript frameworks add to their AJAX requests, but note that anyone can forge such a request - you can't be sure it's really an AJAX request coming from your webapp and not someone replicating the AJAX request manually, using curl or similar.

3
  • Oh, great, that'll at least provide some sort of barrier to direct access through the browser,
    – Aj334
    Oct 6, 2015 at 15:28
  • Do I just add that inside the location ^~ /include/ { deny all; } block?
    – Aj334
    Oct 6, 2015 at 15:29
  • Can't seem to find any result other than CORS and adding a if ($request_method = 'OPTIONS') {} block. Sorry for multiple comments btw, I kept pressing return to go to the next line.
    – Aj334
    Oct 6, 2015 at 15:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .