0

Scenario:

I have a webserver running nginx. I have my html files in /var/www/ and pictures in /var/www/pictures/ However, I also have some secret pictures in /var/www/pictures/secretpics/ which I must keep hidden.

So I updated my nginx conf with:

location /pictures/secrectpics/ {
   deny all;
   return 404;
}

So I tested this in my browser. I typed in www.myexamplesite.com/pictures/secretpics/secret01.png and received 404. (assuming that secret01.png is a real picture.)

Questions: 1. Is there a way to circumvent this and actually get access to secret01.png?

For example, is something like the following possible? www.myexamplesite.com/pictures/../pictures/secretpics/secret01.png

  1. If the above is possible, how should I secure my secretpics?
|improve this question
  • 3
    I know you're actually asking if there are other attacks you should be worrying about, but for this specific one: did you try it? Specifically, try it with telnet as most browsers or other utilities (e.g. wget) will pre-filter the ../ (as you can see for yourself by checking your logs when testing). Also, the general name for the attack you're asking about is directory traversal. – drewbenn Aug 24 '17 at 5:43
  • I tried in telnet, it did not work... (unless I telnet'ed wrong??) – power Aug 24 '17 at 6:26
  • 1
    What did you try, what did the logs show, and in what way did it "not work?" Did it "not work" because the server behaved the way you expect, or because you didn't connect to the server at all? Also, in general, are you looking for, "how do I secure my nginx installation?" (in which case you should read the docs and probably ask on an nginx-specific forum), or, "what do I need to do to secure my data from arbitrary attackers?" which is a great question here but depends on (and we're going to ask you a bunch of questions about) how important your data is and who the attackers might be. – drewbenn Aug 24 '17 at 6:32
  • 1
    How about GET /pictures/doesnotexist/../secretpics or GET /pictures/secretpics/../secretpics/ or GET /pictures/secretpics/doesnotexist/../ or GET /pictures/secretpics/accessallowed/../? I expect them all to 404, also, but they could follow different paths in nginx's code and one of those paths could potentially have a defect (most likely not -- it's a pretty well-tested code base -- I'm just pointing out the difficulty of verifying behavior experimentally). – drewbenn Aug 24 '17 at 16:46
  • 1
    No. cf fuzzing, though. – drewbenn Aug 25 '17 at 3:10
1

Two can keep a secret if one is dead. You secure something by not making it available. At all.

Obviously, that's not practical. So you think about all the ways that someone can get your data:

  • Server mis-configuration allowing online access. Directory traversal attacks are one example of this. Reading and understanding the documentation and applying security updates are good defenses against this.

  • Just guessing. Everyone loves to hate on security-by-obscurity, but sometimes it works pretty well. Use a long name with random characters (think "a good password"), not just secret.

  • Sniffing the data: use https!

  • MITM attacks: respect certificate errors. Train your users. And hope for the best (a really good MITM attack won't be detected; consider using client certificates, too).

  • Direct attack on the server: secure the data "at rest," as much as possible. Anyone with physical access to your server (at any time without full-disk encryption; or while the server is running (e.g. if your data is in a data center or hosted by a company) can see it).

  • Attacking the viewers: secure the data on the remote computers, not just the webhost. For example, can someone get to your web browser's cache on your laptop after you view the files?

  • Insider attacks: can you trust all the people who are authorized to view the data? What if they forward it to "a friend?" Or re-post it publicly? Or send it on to a newspaper or the police? Some good advice I've heard is, never put something online you wouldn't like to see printed in the newspaper.

  • The Man: how will your defenses stand up against a warrant? Do you need to prepare some, ahem, extralegal protections?

  • Bad guys taking a direct approach: how will your defenses stand up against rubber-hose cryptanalysis?

|improve this answer
1

According to RFC 3986 Section 5.4, this has been specified to be resolved as absolute according to the URL itself.

You can imagine the ramifications of allowing double dots go unchecked until they are used to reference a real server file.

I did a test using wget and the requested URL was converted to an absolute URL.

This obviously relies on the client code requesting the resource and server to resolve URLs before they are used within the server. The server software, which in the majority of cases would be Apache, NGINX, IIS or similar, should never trust anything coming from the client.

$ wget https://www.nytimes.com/section/world/../../section/politics
--2017-08-24 17:05:20--  https://www.nytimes.com/section/politics
Resolving www.nytimes.com... 151.101.29.164
Connecting to www.nytimes.com|151.101.29.164|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 127149 (124K) [text/html]
Saving to: ‘politics’
|improve this answer
  • 1
    wget collapses the URL before transmitting it OTA, though. You need something more-manual, like telnet, if you're testing the server's behavior. – drewbenn Aug 24 '17 at 16:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.