Attacking my URL

June 20, 2007 7:00 PM

How do I prevent hackers from embedding scripts into my site's incoming urls. For example, a hacker can easily create a link like link with javascript to ultimately grab users cookies. How do I prevent this from happening. Can I use javascript to prevent this, or is this something that need to be prevented on the server end?
posted by kaizen to computers & internet (10 comments total)

I don't understand the question. Do you run propmart.com? If so, what you need to do is fix your code as to not so implicitly trust the values in the query string.
posted by xmutex at 7:03 PM on June 20, 2007

That's my question. How do tell my server / or the client not to implicitly trust URL's with javascript inside them? What code do I fix? Can this be accomplished with javascript, mod_rewrite, httpd.conf, etc. etc. I have no idea where start.
posted by kaizen at 7:08 PM on June 20, 2007

Escape it before printing it in the HTML. Whatever language you're using should have an escape() function for this purpose.
posted by smackfu at 7:11 PM on June 20, 2007

This isn't the right way to solve the problem. You need to code your application (i.e. the ASP/VBScript) to prevent this from happening. Every single bit of data that could come from a hacker (form POST data, urls etc) must be "escaped" to make sure it only contains what you're expecting (often this means you only want letters and numbers, and no symbols). This practice of stripping out everything except letters and numbers is called white-listing, and is a far better option than black-listing, which is where you define 'bad' characters (like < and &gt:) and only strip them out.

This should all take place in the server. It doesn't make sense to define complex mod_rewrite rules to try and "fix" this because mod_rewrite rules will rapidly become incomprehensible and unmaintainable.
posted by Aloysius Bear at 7:16 PM on June 20, 2007

Well, it depends on exactly what you're doing with those URLs, but generally speaking you don't want to output user-submitted data directly in your page. You should always, always either escape it, check it, or filter it.

Escaping would mean replacing special characters with their escape sequences. For example, turn '<' into '&lt;' and '&' into '&amp;'.

Checking would mean looking for special characters and rejecting to display the entire string if it looks suspicious.

Filtering would mean stripping out special characters entirely.

Escaping is usually the "right" way to handle this. You will want to do it on the server side, definitely. Whatever server-side programming language you're using should have built-in functions to escape strings—htmlspecialchars in PHP, for instance.

(I'm pretty sure my second paragraph is going to get mangled, what with all the fancy ampersandin'. Apologies in advance!)
posted by Khalad at 7:16 PM on June 20, 2007

The issue you're facing is known as 'data validation'. It is the biggest problem faced by web applications.

I disagree with other posters here on how to address it: I don't think you should escape/disallow special characters (quote, $, &, < ,>, etc) -- rather, I think you should only allow regular characters ([a-z], [A-Z], [0-9]).
posted by Jairus at 7:31 PM on June 20, 2007

Whitelisting characters may become less manageable as well in a multilingual environment.
posted by gimonca at 8:26 PM on June 20, 2007

I'm sure there are regex expressions for the 'alphanumeric' set of any given language.
posted by Jairus at 8:52 PM on June 20, 2007

I might normally agree with Aloysius Bear and Jairus about black lists vs. white lists. But HTML/XML is a well understood, well documented standard. You should be escaping nearly all data you display anyway... there's no reason to limit yourself to just alpha/num.

So look through the docs and find ASP .Net's HTML/XML escaping function. Then apply liberally.
posted by sbutler at 9:23 PM on June 20, 2007

It'd be a good idea to get someone to go right through that site checking the validation and escaping. There may well be several vulnerabilities, and you also need to watch out for email injection with the feedback form, SQL injection if it directly builds queries, etc.
posted by malevolent at 1:24 AM on June 21, 2007