50

I have a simple login form on my web page and the URL looks like this:

example.com/signup/signup.php?q=1

If I try something like this:

example.com/signup/signup.php?q=1&()

I'm redirected to a stack dump that looks something like this:

exception 'DOMException' with message 'Invalid Character Error' in /<mydirectory>/a_xml.class.php:74
Stack trace:
#0 /<mydirectoy>/a_xml.class.php(74): DOMDocument->createElement('()')
...
#6 {main}

Is this a big problem in terms of security? Are there any attacks a malicious user can perform that will allow him to deface or steal my database? Or is this relatively benign and I can ignore it?

7ochem
  • 103
  • 5
Kevin
  • 501
  • 4
  • 3
  • 30
    If adding a simple &() to the back of a query show this stackexchange. Remove the application from production, fire the guy who wrote this and continue from there. I bet if you change the q= to something funny you will to get some nice supprises. – Pinoniq Mar 24 '15 at 13:35
  • 9
    Although security by obscurity is a bad thing, nobody says that telling everybody how your system works is smart. Obscurity *added* to other security measures can help a bit, or slow down attackers and let you discover the threat before. – Bakuriu Mar 24 '15 at 14:03
  • I wonder about this too, and the answers so far don't seem to really address the question. OBVIOUSLY any error that causes a stack trace to be shown is a bug that should be fixed. This particular case MIGHT indicate a potential SQL injection problem, and if so that's a huge security hole and should be fixed. But the question was, Does it create a security hole for the user to see a stack trace? I often hear people say that such messages show a potential hacker information about internals that could be exploited. But, such as what? So a hacker learns that I have a ... – Jay Mar 24 '15 at 14:03
  • 7
    The basic principle is 'the less information revealed the better'. Some people don't even display the server version. – Chloe Mar 24 '15 at 14:08
  • ... function named "foobar". How does this help him? Maybe he can see that I am using the mysqli library. I suppose you could say that if he figures out that I am using a particular version of some package that has a known security hole, he could exploit that. But he could try an array of known security exploits anyway, so hiding which particular version I have seems a weak defense. – Jay Mar 24 '15 at 14:09
  • In addition to not showing it to the user, remember also to try/catch anything sensitive to make sure that a stack trace cannot escape out to the logging system. – Rob Mar 24 '15 at 15:32
  • 6
    Let me ask you this: why did you feel the need to sanitize `` when posting the question? Unless it was purely to ease readability, there was no point to strip it out. :-) – smitelli Mar 24 '15 at 18:57
  • 6
    The directories, source file names, function names, etc. aren't so big of a deal in this example, as much as finding out that the string after the `&` is potentially passed to a `createElement` call as-is. That is valuable information to a potential attacker, much more so than any file names or line numbers or whatnot. Basically, since you can't easily predict what all possible error messages *themselves* will say ahead of time, you don't want to display them and run the risk of unexpectedly exposing details of a flaw before you find out about it yourself. – Jason C Mar 25 '15 at 06:14
  • @Jay I remember a few months back in school, our teacher taught us about security and we were 'hacking' in a learning environment and we could do so much with just knowing the structure of the directory. Cant remember what the method is called or how to do it anymore. – Loko Mar 25 '15 at 09:15
  • 2
    @chloe et al: Ok, I get the argument: Why take a chance telling a hacker anything? Even if I don't see a way to exploit it, maybe the hacker knows something that I don't. But anything more specific? – Jay Mar 25 '15 at 13:07
  • @Jay, The stacktrace contains argument values... Now what if in your stack you have a method taking your sql connection string as argument ? Information about callstack and files might help the hacker exploit a breach elsewhere, he works faster and will be harder to detect and stop on time. – Guillaume Mar 25 '15 at 13:18
  • 2
    @Chloe: Bruce Schneier has a story, he configured his (I think mail) server to lie about its version number. He was forced to change it to not report a version number at all, by the volume of triumphant mail from people who'd spotted that Schneier was running a version known to be exploited ;-) – Steve Jessop Mar 26 '15 at 12:16
  • @SteveJessop: Why didn't he just change to a version that was not exploited o.O – Lightness Races in Orbit Mar 26 '15 at 16:56
  • 1
    @LightnessRacesinOrbit: I assume because he didn't want to have to keep changing it. Also I expect there's a real risk the only unexploited version is the latest, and the whole point was not to tell the truth. – Steve Jessop Mar 26 '15 at 17:23
  • @Steve: He should keep all services up-to-date. :( What a terrible way to "secure" his system. I thought he was supposed to be an expert? – Lightness Races in Orbit Mar 26 '15 at 17:24
  • 1
    @LightnessRacesinOrbit: of course he kept the service up to date, he's as much on the patch treadmill as anyone else. I'm talking about what version number it reports, not what version it really is. Of course a dedicated attacker will probe the service anyway to work out what version it is regardless of what it reports. I don't think it was intended to be a serious security measure, just hygiene. – Steve Jessop Mar 26 '15 at 17:24

6 Answers6

67

On production (contrary to development) environments, stack traces and error messages should be logged to file instead of dumped on screen. This is because an attacker may learn things about your system that could help compromise your system.

Information such as operating system, web server version, PHP version and more. Some stack traces may contain system/environment variables that should not be made public!

The user/visitor should get a nice looking HTTP error page instead of a message that is of no use to the visitor.

Danny Beckett
  • 109
  • 4
Alasjo
  • 973
  • 6
  • 10
  • 24
    [CWE-209: Information Exposure Through an Error Message](http://cwe.mitre.org/data/definitions/209.html) & [CWE-756: Missing Custom Error Page](http://cwe.mitre.org/data/definitions/756.html). – mr.spuratic Mar 24 '15 at 10:04
  • 9
    And stack traces in production is so '90s – atk Mar 25 '15 at 00:26
  • 5
    Adding to the list in the second paragraph (although it is implied by the first paragraph), an attacker can learn what your bugs are and exploit them before you have a chance to notice them. In the OP's case, we can see that it's possible that the string after the `&` is being passed directly to a `createElement` call. An attacker immediately can start experimenting. On the other hand, if it is logged only, while it is still a weakness it is at least not announced, and presuming you pay attention to your error logs (which you should) you have the chance to fix it before anybody notices. – Jason C Mar 25 '15 at 06:12
  • 1
    Information such as operating system, web server version, PHP version and more are often included right in the HTTP headers, no need for a stack trace. – dotancohen Mar 26 '15 at 13:30
  • 1
    I agree with this answer, but it seems to me that the main reason they're not shown on production sites is they are not a useful error screen. – Joe Mar 26 '15 at 20:04
  • So security through obscurity is useful after all, who knew. – user541686 Mar 28 '15 at 08:58
26

There are two different aspects to this:

  • Is the bug causing the stack trace a security vulnerability.
  • Is the framework configured to show stack traces to outsiders.

The error message Invalid Character Error sounds a lot like forgotten escaping, which can very often be exploited in some way. So you should be concerned about the stack trace because it is a symptom of a possible security vulnerability.

The other question is whether you should be concerned about stack traces being showed to outsiders. On one hand hiding information about the internals of a system is could be seen as security through obscurity. In most cases I would agree with that, but not in case of stack traces.

The stack traces only show up when there is a problem, so if there ever is a stack trace there is a significant risk that there is a bug, and if there is a bug there is a significant risk it can be exploited. Hence keeping stack traces away from outsiders is a good idea. Moreover if the stack trace contains not only names of the called functions but also parameter values, it can easily leak keys, passwords, cookies, or other kinds of credentials.

For both of the above reasons, it is important to be careful with where your stack traces show up.

It is however important that the stack traces be available to those who need to fix the problem. So logging of stack traces is important. If those cases where the stack traces are indications of actual security vulnerabilities, you want to fix them ASAP. Even though a non-descriptive error message won't give an attacker much to work with, simply from realizing which characters work and which don't, they can possibly figure out how to exploit it anyway.

kasperd
  • 5,402
  • 1
  • 19
  • 38
  • 7
    +1 for being the only answer so far to notice that, besides the stack dump, this sure looks like an injection vulnerability. – Mason Wheeler Mar 24 '15 at 12:24
15

There are two issues here, and the OP asks about the less important issue.

Showing the trace

This is the issue that the OP asks about. There are debates regarding how much of an issue showing a trace is in general, and this particular example displays nicely that displaying a trace can be a security issue. The reason for that is that it lets us (you, me, and the hacker) know about the existence of the second issue.

Not filtering user input

This is a real problem. Not only do I know (thanks to the trace) that your application is passing unfiltered and unvalidated user input to the native PHP functions, I even know that DOMDocument->createElement() is the function in question. Now I'm going to start attacking this site and all sites that I can identify with this company for other filtration issues, such as SQL injection, XSS, CSRF, ad nauseum.

dotancohen
  • 3,698
  • 3
  • 24
  • 34
  • 1
    Thank you. This is the most correct answer and draws attention to the fact that stack dumps can range from completely harmless to indicative of major problems. Too often in security we get binary answers and treating all security problems equally. We're always limited in resources in what we can do, so triage is extremely important. – Steve Sether Mar 26 '15 at 15:01
7

Notice that stack traces include parameters. If there are function calls that pass in passwords as arguments, those will end up in stack traces.

It's obviously a disaster if one user can cause the password of another to be displayed back at him. Less obviously, user passwords are now sitting in log files; which will make your users very mad. At the very least, you need to make sure that password logging doesn't happen.

Rob
  • 639
  • 3
  • 9
4

In your example, the people can see the structure of your directories which they could use for potential attacks. You'd be surprised how much a 'hacker' can do with very little information. So Yes in general it's a big problem in terms of security. Like Alasjo is saying, it's also not user friendly and an error page is a good alternative.

For example in some cases of showing errors to the users could lead to: Path Traversal

Path traversal is also known as the ../ (dot dot slash) attack, directory climbing, and backtracking.

Loko
  • 141
  • 6
0

While it's been alluded to in the comments above, it might be useful to note that one reason

"Information such as operating system, web server version, PHP version and more. Some stack traces may contain system/environment variables that should not be made public!" (See comment above by @Alasjo and @Danny Beckett)

is bad, is because knowing the software stack used to build your application, allows attackers to exploit security flaws in those components (Security issues in common software is widely publicized information (see https://cve.mitre.org/) ) in addition to any flaws/defects in your application made apparent in the stack traces.

For example, since I know your site uses PHP now, I might try all PHP related security flaws (in the event that you've not patched your PHP installation to address that flaw... you do keep your software stack patch levels up to date right? :-)) even if your application did not expose any of its own flaws in the stack trace.

gentwo
  • 1