Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If a site is written poorly enough, is it possible to take it down or severely mess with it using only javascript in the URL bar?

share|improve this question
Is there a specific reason that this question came up? It seems very vague... – pkaeding Nov 22 '10 at 1:40
If you're going to execute Javascript on an arbitrary page I suggest you use Firefox's Firebug extension (console pane). – Olivier Lalonde Nov 22 '10 at 1:52
This question doesn't strike me as an IT Security professionals question. Obviously if something is 'written poorly enough' it will be possible to take it down using method 'X' - I think a more useful question, but not necessarily appropriate for a 'white hat' security forum would be to ask for types of URL attacks which are known to impact web sites effectively. – Rory Alsop Dec 2 '10 at 18:08
up vote 8 down vote accepted

Yes, in theory, a site could have a javascript function that will initiate an AJAX call to destroy the site. Then, you could just enter:


I can't think of why a site would have a destroySite function, but it is theoretically possible. More likely would be some sort of search function, which is vulnerable to SQL injection:

javascript:search("'; drop table users; --");

I should add that these attack vectors rely on server-side vulnerabilities, and you should shore up your server-side code to protect against SQL injection, and make sure that you authenticate any AJAX requests that should require authentication, before allowing them to change anything on the server.

Essentially, the bottom line is: Never trust user input, and AJAX requests are user input

share|improve this answer
Exactly, I was wondering about injection through javascript. – Moshe Nov 22 '10 at 1:42
@Moshe cool, I'm glad that helped. I added a bit to my answer about where the problem in such a site would exist (its not in the javascript) and how to protect your site. – pkaeding Nov 22 '10 at 1:48
Just to add to that, WCF, and oData counts as user input as well. Some people may not know of these new Microsoft Technologies. – LamonteCristo Nov 22 '10 at 19:50

The javascript: scheme executes Javascript statement(s) in the context of the current page. You could achieve the same effect by writing or pasting Javascript snippets in the Firebug's console. So if the site can be "brought down" by some Javascript running in the context of the current page, it is possible (either through javascript: in the browser window, with the Firebug or other web console).

But javascript: (and data:) URL schemes do pose special problems with cross-site scripting attacks - it is often possible to "take down" (compromise) the USER. If the site allows injection of the user data into URLs and does not properly validate the incoming data, it may create a cross-site scripting hole. For example, consider a page that takes a cgi parameter lastpage, filters all the tags and quotes from the input, and echoes the filtered input inside of the tag: ">Click here to go back

If the attacker gets a user to click on the url where the lastpage cgi parameter is: lastpage=javascript:alert(document.cookie) the site could end up with: Click here to go back (note that there are no tags or quotes in the injected data). When the user click on the link, the injected Javascript is executed (sometime called "one-click XSS" since it often requires user interaction for execution) - of course, in the real attack, it would not do an alert but instead run a script that sends the stolen cookies to the attacker's site, or does something equally nasty).

The right thing to do is to remember where on page the filtered input will be used (in which context - in this one, the URL one) and adjust the filtering accordingly - for example, verify that the scheme is limited only to http:// or https:// .

The filtering of URLs and avoid the javascript: injection attacks is not (yet) reflected in the OWASP XSS Prevention Cheat Sheet

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.