On Language and XSS
While I tend to be very aware of my own use of language, and most of my own errors in the way I word are deliberate, I'm not really one to correct people. The way I see it, as long as they communicate their message, they've done an adequate job. Sure, there's always room for improvement, but we're all in a different place. That said, I've been fascinated for a long time by the way that language and psychology work together in both verbal and nonverbal communication, and it's something I feel like I can speak to. Consider this my first of many posts about how we can all improve our communication skills. Whether we're researchers reporting a bug, pentesters presenting results, CISOs trying to help management understand the importance of what we do, or developers discussing the pros and cons of a new feature, we all have a message to communicate. We all feel like we're not being heard, and we all feel like what we're doing is important. Might as well do what we can to help other people "get it".
We all know the difference between a vulnerability and an attack, but often mix them up in vulnerability reports, technical documents, and normal conversation. The issue on my mind today- "XSS Vulnerability."
I know I'm going against popular usage of the term here, but it has always irked me. Cross-Site Scripting is not a vulnerability, at least not for websites (it could be argued that it is a weakness for browsers). When explaining XSS to a layperson, we usually start by saying that it isn't necessarily cross-site, and it doesn't necessarily require scripting. Talk about poorly-chosen words.
When I use XSS, I'm usually exploiting an HTML injection bug. Sometimes I'll exploit a Javascript injection, CSS injection or other type of markup/code injection bug. Why not call it what it is? If we all start calling the vulnerability by a descriptive name, when we refer to XSS (the attack), it's actually appropriate, descriptive, and useful.
When we write vulnerability reports, assessments, technical documents, or even blog posts, precision is key. I'm personally guilty of the usage above (and again, I'm not going to correct anybody), but we really should be more careful about which words we use. I couldn't care less about "correct" use of language, but when our points aren't being communicated, it may be worth a bit of effort to fix.
We all know the difference between a vulnerability and an attack, but often mix them up in vulnerability reports, technical documents, and normal conversation. The issue on my mind today- "XSS Vulnerability."
I know I'm going against popular usage of the term here, but it has always irked me. Cross-Site Scripting is not a vulnerability, at least not for websites (it could be argued that it is a weakness for browsers). When explaining XSS to a layperson, we usually start by saying that it isn't necessarily cross-site, and it doesn't necessarily require scripting. Talk about poorly-chosen words.
When I use XSS, I'm usually exploiting an HTML injection bug. Sometimes I'll exploit a Javascript injection, CSS injection or other type of markup/code injection bug. Why not call it what it is? If we all start calling the vulnerability by a descriptive name, when we refer to XSS (the attack), it's actually appropriate, descriptive, and useful.
When we write vulnerability reports, assessments, technical documents, or even blog posts, precision is key. I'm personally guilty of the usage above (and again, I'm not going to correct anybody), but we really should be more careful about which words we use. I couldn't care less about "correct" use of language, but when our points aren't being communicated, it may be worth a bit of effort to fix.


1 Comments:
I completely agree. I have also noticed a similar trend in training modules/classes that are designed to help developers code more securely. In most classes they always start out with what amounts to "look at what an attacker can do to your code". They generally start out with XSS attacks and move on to SQL Injection, but at the end of the day isn't the class supposed to be about how to write secure code, and not so much about what an attacker can do if it isn't?!?
Instead, I believe that these classes should start from the approach of security fundamentals like Validate Your Input, Encode Your Output, Use Parameterized Queries, etc. You know, solutions that you can give developers along with code snippets they an take back and study and compare to the way they are coding now. Then, AFTER the precautions have been put in place demonstrate how those mechanisms prevent common attacks such as XSS and SQLi and others.
Just my $0.02 on what seems a completely backwards approach to doing something.
By
Matt Presson, At
May 26, 2010 5:48 PM
Post a Comment
Subscribe to Post Comments [Atom]
<< Home