dcsimg
www.webdeveloper.com
Results 1 to 7 of 7

Thread: Javascript Address Bar Injection

  1. #1
    Join Date
    May 2006
    Location
    North of the South Pole
    Posts
    590

    Arrow Javascript Address Bar Injection

    I was surprised to discover the lack of information on this subject when I searched this topic on Google.

    I kind-of have a double question. First, is there any way to block users from injecting javascript into a web page via the address bar? There is probably no solution to this, though I saw something about a "filter", though that may have been referring to something server-side.

    Second, is there a way to tell if the code run is "authentic" (meaning called by the original javascript and not by the address bar), specifically regarding AJAX? Even if you have security measures in place, it is always possible to make a false AJAX request using javascript injection.

    For example, say that you're programming a chat system using AJAX. Let's say that you have an option where you can, say, change the color of your current message. You have javascript written to check whether that color matches the color of the other user's messages. If so, it blocks an AJAX request. However, using javascript injection, you can make that "illegal" AJAX request.

    That is a very bad example, but you get the idea. My overall question is this: What sorts of measures can you put into place to repel client-side javascript injection?

    Please note: The example is made-up, so please don't post suggestions about how I can improve it. It is there for the sole purpose of describing this type of javascript injection.

    .
    "I have no special talent. I am only passionately curious." Albert Einstein

  2. #2
    Join Date
    Dec 2003
    Location
    Bucharest, ROMANIA
    Posts
    15,428
    By short, as far as I know, you can not prevent javascript injection and you can not verify the authentication of the code with maximum accuracy. So far, the only way you can 100% protect against javascript malicious injection is disabling javascript (in the browser's options/preferences) before entering the untrusted web sites.

    Of course, all the browsers' creators/vendors are worried about that, but their efforts are not yet coordinated, thus each browser has weaknesses/solutions.

    For instance, regarding the XSS, CSRF, and malware-laced iframe attacks: Mozilla claims to have improved the security by releasing an add-on - Site Security Policy:
    http://people.mozilla.com/~bsterne/s.../download.html

    But even the "trusty", secure sites, could not be what they look like. In theory, the hash could be copied and can enter in collision.
    In his blog, Eich Brendan, the inventor of Javascript (and manager now at Mozilla) seems concerned about the hash collision:
    http://weblogs.mozillazine.org/roadm...hives/2008/04/
    (bellow, last paragraphs)
    The comments to that article in blog are interesting as well.

    You may also be interested about the future of Javascript (Javascript 2) as Eich Brendan sees it (an interview - June 23 2008):
    http://www.infoworld.com/article/08/...terview_1.html
    Last edited by Kor; 07-23-2008 at 02:29 AM.

  3. #3
    Join Date
    Jul 2008
    Location
    urbana, il
    Posts
    2,787
    the only thing you can do is validate the request on the server.

    once you hand the page over to a client, you have no technical control over how it might be used. i prefer pasting into firebug's larger command line, a virtual console. bookmarklets are another example. greasemonkey is an automated way to it.

    i always tell people

    "javascript can run, but it can't hide"

  4. #4
    Join Date
    Dec 2003
    Location
    Bucharest, ROMANIA
    Posts
    15,428
    Yes. The other aspect of the XSS - bypassing the genuine javascript filter, is to be solved, as rnd me said, by double checking the request on the server-side level.

  5. #5
    Join Date
    Mar 2005
    Location
    Sydney, Australia
    Posts
    7,974
    Most browsers (for example IE, Firefox, Opera) allow the browser owner to set up user JavaScripts that are automatically added to any/all web pages that they visit. There is nothing the web page owner can do to even tell that this has been done - it is just the same as when people override your stylesheet with their own. The web page author only has full control of the HTML.
    Stephen

  6. #6
    Join Date
    May 2006
    Location
    North of the South Pole
    Posts
    590
    Wow, thanks for all of the responses!

    I understand the risks of XSS and CSRF and how to prevent them (or in the case of CSRF, "beef up" security to reduce the likelihood that the would occur). I was wondering about a different kind of attack (though it is not really an "attack"). The corny chat room example somewhat showed this type of injection. Here's another example:

    Say you're programming a javascript game. You use AJAX to send the score of the player to
    the server for logging. After looking at the script, a malicious user could run your AJAX code
    to send a score of 1,000,000 even if they earned only 5,000.


    This example is a bit better (though it's still fictional ). Based on what you all have said, you can't prevent something like this from happening on the javascript side. However, is there some way to authenticate AJAX requests on the server side in a situation like the one described above? For example, is there a way to pass a security "token" to javascript that a hacker couldn't get ahold of?


    .
    Last edited by shane.carr; 07-23-2008 at 05:59 PM.
    "I have no special talent. I am only passionately curious." Albert Einstein

  7. #7
    Join Date
    Jul 2008
    Location
    urbana, il
    Posts
    2,787
    security is an illusion.

    for example: you could buy medico locks, and ADT alaarm system, and what do those do to pervent someone driving a pickup truck through the bedroom wall and grabbing your wife in the middle of the night. Rather an extreme example, i don't mean to frighten.

    Indeed your medico locks will keep the crackhead from walking off with you dvd collection. but they probably wouldn't stop a professional cat burglar. And what would they to to an ID thief who taps your landline and reads your mail? Its all a battle of wits and odds.

    E-security is little different. you don't know who your attacker is, or what their skill level may be. you could devise a very clever system that encryped everything, validated every bit, and someone would still find a flaw (if they wanted to put the time in).

    Javascript in particular is challenging because everything has to be done in the open: there is no hiding.

    That being said, lot of brilliant programmers know little of javascript. obscure your code, validate every input on the server, and hope for the best. in your game analogy, you could figure out the best possible score that a player could legitimately earn, and ban any detected cheaters. Use the best tools and techniques available, and don't make cheating any easier than it has to be.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles