maluc brought up a good point yesterday about the use of client side protection against exploitation that I really haven’t spent much time talking about, because it seems so trivial from a web application security perspective. However, I see it happen extremely frequently in regular application tests and I think it’s worth spending a few minutes writing about because it’s not just terrible coding practice, given that some browsers don’t have JavaScript enabled but, it is also a slipperly slope towards greater insecurity.

Here’s a quote that maluc brought to my attention from w3schools.com:

Form Validation

User input should be validated on the browser whenever possible (by client scripts). Browser validation is faster and you reduce the server load.

You should consider using server validation if the user input will be inserted into a database.

That’s a very sad statement coming from one of the top sites out there for technical resources on programming. Let me re-state what they said but correctly:

“User input should be validated on the browser whenever possible (by client side scripts) only as a consumer benefit. It should be always verified by server side scripts regardless of additional resources required as this is the only way to avoid exploitation via circumvention of your client side validation.” -RSnake (you can quote me on that one)

I see this happen all the time actually, I probably see it two or three times a day during regular application testing. The programmer puts some client side validation in there like “Your email address must be in the form user@somewhere.com” so I can’t submit to the next page. However, 9 times out of 10 I can quickly circumvent this stupid protection by simply turning off JavaScript. There is the occational form that also uses JavaScript to construct the URL to post to, which takes more than simply turning off JavaScript but that too is trivial to get around by modifying the JavaScript returned to you with something like burp proxy (it’s not just helpful for sending different data, it’s also helpful for changing the data as it is presented to you).

By entering some bogus information in the URL field I can get it to error out (assuming the client side script is built with any protection at all) and then by changing the post method into get with the webdeveloper Firefox plugin you’re off to the races with a functioning XSS exploit - complete JavaScript circumvention within 5 minutes if you know what you’re doing.

There are equally as many pages that use only JavaScript validation and if you turn off JavaScript it will happily submit whatever you entered (gah!). I’m sure there are some helpdesk people with some weird crap in their email as a result. Without server side erroring XSS may go away but then the service itself is exploitable (SQL injection, pipes, null byte injection, etc… etc…). Eesh! The moral of the story is don’t use JavaScript validation alone. It’s risky and opens you up to even greater issues if you rely on it as your sole security validation mechanism.

This entry was posted on Friday, October 6th, 2006 at 9:24 am and is filed under XSS, Webappsec. Responses are currently closed, but you can trackback from your own site.