[RETRACTED (never mind)]Security issue: Injecting a single quote in the URL

Never mind on the following issue. It turns out the error was caused by a script used on the site. Not a security flaw.

--

I’ve been taking a look at MODx security issues and applying a few different url injection tests. This one may not be the biggest threat to security, but it does expose the technology being used (MODx), the database (MySQL), and the full file path on the server to the manager. If you insert a single quotation mark in the URL -- like so: mysite.com/random_alias’ or like so: mysite.com/random’alias (anywhere in the URI, including any query strings) -- you will see a MODx error message that discloses too much information.

I’ve noticed that the manager doesn’t let you save aliases with single quotation marks -- it strips the quotation mark -- but if a malicious person is trying to crack the web site, they can still type one in the web address. When they do, they get the MODx error message, which is a generous gift of information. Of course they’d have to go a lot further, but why disclose enough information to take them to the next step?

I tested this on 0.9.6.1p2

Could you provide a little more information (e.g. what script?) so others can avoid this situation?

The script was written in-house. It was a script written for the 404 error page that took the REQUEST_URI and searched a database table of redirects (old URIs with their equivalent new MODx ID). The problem was with the part of the script that took this value -- $_SERVER[’REQUEST_URI’] -- without performing any sanitization algorithms on it. I have some algorithms in the apache config file that check for common url injection techniques, but the single quote was not in those algorithms. I can’t exclude the single quote character completely from web addresses, so I don’t think I can add the single quote (at least not by itself) to the list of suspicious characters in the apache config file. For the time being, I have done this to convert the single quote to the ascii equivalent:



And made a similar change in the database query to make sure that I’m accurately comparing the bad URL to the one in the database.

Extending this situation out to other circumstances, though, I can see that it would be good to have some way to control the kind of error messages shown to web users in the case of database or php problems. There probably ought to be a way to turn verbose error messages off in the MODx configuration. There are unlimited ways to code something incorrectly, and it’s difficult to control for them all, but it would be nice to be able to control how MODx handles those errors. Maybe there could be configuration settings with options like these:

- Debug mode - show verbose error messages always
- Simple error reporting - show only a nondescriptive error message like "An error occurred"
- Manager debug/simple error reporting for end users - show verbose error messages only to users who are logged in to the manager. For all other users, show a nondescriptive "An error occurred" message.
- No error reporting - show a blank page

Or maybe it would be best to set manager error reporting separately from end user error reporting:

Manager error reporting options: 1. debug, 2. simple error reporting, 3. No error reporting
End user error reporting options: 1. debug, 2. simple error reporting, 3. No error reporting.

Indeed it should be configurable; the error handling model in the 0.9.7+ releases will be much more robust and 100% extensible by overriding the default modErrorHandler class, and can even be overridden by context and/or user.

Quote from: OpenGeek at May 14, 2008, 12:03 PM

Indeed it should be configurable; the error handling model in the 0.9.7+ releases will be much more robust and 100% extensible by overriding the default modErrorHandler class, and can even be overridden by context and/or user.

It would be nice if verbose errors could be sent via email to the admin instead of displayed in the browser to the user also.