|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: New Web Vulnerability - Cross-Site Tracing
Date: Thu Jan 23 2003 - 21:41:32 EST
>> = me
> = xss-is-lame@hushmail
>> XSS (including "HTML injection" for those who make such distinctions)
>This is a pretty meaningless statistic unless you can link it, through
I think it's an important stat because *if* XSS becomes widely exploited, then it could pose a significant threat.
>>it seems likely that applications will become a more attractive target
>>to hackers as it gets more difficult to break into servers.
>
>"It seems likely", eh? So in other words, there is no widespread
Agreed.
>The word "plague" has an extremely strong negative conontation.
I think we're looking at this from two different sides: I see a plague in the sense that a large number of applications have these bugs in the first place. You say it can't be a plague until those bugs are being actively exploited. And of course you have a point, but I think it would be best to fix these issues before finding out how serious they can be. That practice seems to have worked well in the past ("non-exploitable" heap-based buffer overflows come to mind). In addition, strategically speaking, I think XSS is a good "learning tool" for educating programmers about trusting input, and the involvement of three parties in XSS (attacker, victim, and server) introduces an additional layer of complexity that is useful in demonstrating that attack scenarios do not necessarily need to be perfectly straightforward.
>I would also like evidence supporting your claim that servers are
I don't have statistics. Here's what I meant to say: "servers from major vendors/developers are less likely to be prone to the same-old, same-old obvious vulnerabilities like classic buffer overflows and directory traversal." (Here, I use "classic overflows" to distinguish from things like array index modification, length field tampering, and integer signedness errors that happen to use overflow-style attacks but stem from something other than "really long string.")
By "servers," I mean "software implementations of networking protocols," not physical machines. So maybe we are using different definitions here.
>For the last few years, the trend is the opposite. The widespread
I agree, partially because they allow non-programmers or non-experts to add functionality. But these technologies generally enable the development and deployment of web *applications*, not entirely new servers on a par with Apache. I apologize for not making this distinction more clearly.
>On the other hand, SQL injection is easy.
Yes, but it generally occurs in applications, not the servers that run the applications.
>let's look at buffer overflows, which I'm sure you'll admit are
Agreed, this is a moving target. But at some point in time, maybe we will run out of new ways of manipulating simple inputs in a security-critical fashion, which would leave us with more complex bugs (that would hopefully be more difficult to exploit), and maybe advances in OSes and compilers will help reduce the overall threat even if something new is discovered.
>I'm sure there are arguments to be made for programmers getting better
Agreed, until customers ask for it, and security begins to affect the vendors' bottom line. I believe that's starting to happen, but others probably disagree.
>> Personally, I'm glad to see the contributions made by up-and-coming
I recognize that this opinion is probably unusual. And as you say, there can be many different motivations for finding bugs. Not everyone can do PhD level vulnerability research, but we don't need everyone to be a PhD either.
>I'm no psychologist, but I think that the people that find these XSS
Regardless of their motivations, they still perform a valuable function by identifying and defeating software that is so insecure that simple attacks are successful.
>In a perfect world... BugTraq would only contain posts from qualified
>people with real issues to share.
With the increasing number of vulnerabilities, I'm surprised that we haven't seen a new mailing list with this specific mission.
>Finding XSS bugs is trivial. Much harder than, say, developing an
... and the path of least resistance will not work on software that has been locked down well in the first place. Again I don't have hard statistics, but over the last year or two, it seems that most of the serious bugs in major software were found by top notch researchers, not Jane Doe.
>Theory is theory until proven otherwise. XSS is not appealing to
It doesn't seem likely to me either, but wouldn't it be nice if we prevented such attacks before they happen?
>The bottom line with this whole XSS thing is that it's been blown WAY
I don't think we've seen any proof of widespread exploitation. But that should only affect how XSS is prioritized as a vulnerability class, not whether it should be eliminated or not.
>something that is very dangerous and can directly lead to a server
... which, in the case of e-business, is equivalent to a server compromise if it allows theft; or, in other cases, equivalent to violations of privacy. At the end of the day, the server does not matter, rather its users.
>Please read what I've written here and consider it seriously.
It has helped to clarify some of my own thinking.
I'm not saying that XSS is as much of a threat as buffer overflows. And maybe it won't ever be widely exploited, for whatever technical or social reasons that may come along. However, its prevalence is a reflection of some widespread, fundamental gaps in secure programming and testing. And I don't think that the vulnerability research community really fully understand XSS as a class. Look at the varying analyses that have come out regarding the XST issue.
>Whether or not your predictions occur *will* reflect on your
Hopefully enough people will concentrate on your technical arguments rather than what email address you happen to be using.
- Steve
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:47 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |