Is it possible to take down a site using javascript in the URL bar?

Question

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?

Answer 1

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:

javascript:destroySite();

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

Answer 2

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 https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet