Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cross-site Scripting Prevention

Posted by michael on from the do-your-part dept.

An anonymous reader writes "Cross-site scripting (XSS) occurs when an attacker introduces malicious scripts to a dynamic form that allows the attacker to capture the private session information. This article casts light on the areas vulnerable to XSS exploitation, explains how the user can protect himself, and details what the webmaster can do to secure a site from this type of malicious intrusion."

4 of 27 comments (clear)

  1. hey! cool! by Anonymous Coward · · Score: 2, Interesting

    slashcode developers could learn from this, given their track record with XSS vulns:

    http://www.securityfocus.com/archive/1/280218/2002 -06-28/2002-07-04/0

    (also provides a good example for people asking "what's an XSS?")

  2. site redirects by stonebeat.org · · Score: 4, Interesting

    hehe.. this reminds of the time, when people used to embed redirects tags like:

    <meta HTTP-EQUIV="Refresh" CONTENT="0;URL=http://www.xml-dev.com">

    in messages on the online forums. I know Hypernews was vulnerable to this attack.

    --


    Consensus is good, but informed dictatorship is better
  3. PHP by LordLucless · · Score: 3, Interesting

    Now, maybe I don't know enough about XSS vulnerabilites, but PHP provides a function that strips all HTML tags from an incoming string (You can provide an array of exceptions if you like), and I remember having seen somewhere an extension that also strips naughty attributes, like onMouse*.

    If you simply pass all form text through these filters, wouldn't that totally get rid of XSS vulns?

    --
    Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
  4. More audits of XSS by ftide · · Score: 3, Interesting

    Hmm from the lack of posts (25 in 24 hours) it seems not enough people are doing their part to shine the light on frequent use of cross site scripting and its abuses. Perhaps that's because still too many coders employ privacy invasive methods in their server-side scripting.

    Security is a parallel, interlocking issue if asking, "where does the data come from and where does the data go to?" (props to an old school EE guru and physicist for this saying) because you can have very secure client- and server-side apps but if the methodology of data retention is flawed you could have a password-less system and the privacy would still be just as bad.

    I've always disliked heavy use of ECMAScript and cookies while debatable as to whether they're XSS or no they're easy to make as gateways to such things.