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

  2. If the above is possible, how should I secure my secretpics?

Improve this question
7
  • 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.
    – user15392
    Aug 24, 2017 at 5:43
  • I tried in telnet, it did not work... (unless I telnet'ed wrong??)
    – power
    Aug 24, 2017 at 6:26
  • @drewbenn It worked as expected - I got a 404 error (as I set up in my nginx config) My question is "what do I need to do to secure my data from arbitrary attackers?" Importance of the data: can cause catastrophic embarrassment if exposed. Who the attackers might be: 1. "customer's pen tester" and 2. someone who is out to embarrass the owner of the secretpics
    – power
    Aug 24, 2017 at 6:39
  • @drewbenn logs show "GET /pictures/../pictures/secretpics/secret01.png" and that it responded with 404.
    – power
    Aug 24, 2017 at 6:43
  • @drewbenn Is there a standard approach to search for these bugs? Or is it just exhaustive search?
    – power
    Aug 25, 2017 at 0:10

2 Answers 2

Reset to default
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
  • -1, it doesn't answer his question at all = useless answer
    – Awaaaaarghhh
    May 2, 2020 at 17:19
2

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
0

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.