48

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?

  • 28
    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
  • 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
  • 5
    Let me ask you this: why did you feel the need to sanitize <mydirectory> 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 6:14
66

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.

  • 23
  • 9
    And stack traces in production is so '90s – atk Mar 25 '15 at 0: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 6:12
  • 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
  • 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
25

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.

  • 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.

  • 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.

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.

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.

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.