XSS = SQLI = CMDi=?
Why do we look at Cross Site Scripting, Command Injection and SQL injection in different ways?
Why am I even writing about such old issues like SQLI, XSS, CMDi? Probably because they are very similar from a builder/prevention aspect but very different from a breaker/defender aspect.
The Result is different:
Cross Site Scripting (XSS): is a payload delivery mechanism. The vulnerability is used to deliver the payload (warhead) in this case client side script which does something. The attack used against a user so the attacker can do other stuff: Malware upload, Social Engineering, Identity Theft etc.
Command Injection (CMDi): A direct attack on a system. Invoking system commands directly. Command injection is a payload attack as opposed to a delivery mechanism.
SQL Injection (SQLI): A direct attack on a system also. Direct access to data or system configuration. The SQL injection attack is also a payload attack.
The Root cause is the same: It all comes down to the same thing:
Mixing up input data with source code / system commands
OR
Breaking out of the data context into the execution context.
XSS causes the browser to execute user supplied input as code. The input breaks out of the "Data" context and becomes execution context.
SQLI causes the database or source code calling the database to confuse data [context] and ANSI SQL [ execution context], Command injection mixes up data [context] and the command [context].
One problem I see is the breakers trying to explain to builders a vulnerability or number of different vulnerabilities all of which to the builder are treated in a similar way (logically) but it all sounds highly complex.
Unless security consultants communicate in "Builder-speak" I don't see how this communication can be effective.
"Hey [builder guy], you have a couple of XSS's in your DOM and also some stored XSS. Coupled with some SQLI some CSRF and some Click-jacking"......who exactly is expected to understand that?
in Builder speak :
"Hey [builder guy], some of the untrusted input, which you render back to the user. This can cause a client side security issue. You need to encode all input from untrusted sources so the browser does not mistake it as code.
You also have a similar issue on your data layer. you need to parameterize untrusted input so it is not confused as code and executes resulting in unexpected issues.
You have some logical issues in relation to how browsers work where requests can be sent on your behalf by using your session, also best not to let your site be iFramed unless you intend it to be this way as it can be used to dupe your clients into doing things they never intended to do."
- which is easier to understand (assuming you are not a security expert)?
Why am I even writing about such old issues like SQLI, XSS, CMDi? Probably because they are very similar from a builder/prevention aspect but very different from a breaker/defender aspect.
The Result is different:
Cross Site Scripting (XSS): is a payload delivery mechanism. The vulnerability is used to deliver the payload (warhead) in this case client side script which does something. The attack used against a user so the attacker can do other stuff: Malware upload, Social Engineering, Identity Theft etc.
Command Injection (CMDi): A direct attack on a system. Invoking system commands directly. Command injection is a payload attack as opposed to a delivery mechanism.
SQL Injection (SQLI): A direct attack on a system also. Direct access to data or system configuration. The SQL injection attack is also a payload attack.
The Root cause is the same: It all comes down to the same thing:
Mixing up input data with source code / system commands
OR
Breaking out of the data context into the execution context.
XSS causes the browser to execute user supplied input as code. The input breaks out of the "Data" context and becomes execution context.
SQLI causes the database or source code calling the database to confuse data [context] and ANSI SQL [ execution context], Command injection mixes up data [context] and the command [context].
One problem I see is the breakers trying to explain to builders a vulnerability or number of different vulnerabilities all of which to the builder are treated in a similar way (logically) but it all sounds highly complex.
Unless security consultants communicate in "Builder-speak" I don't see how this communication can be effective.
"Hey [builder guy], you have a couple of XSS's in your DOM and also some stored XSS. Coupled with some SQLI some CSRF and some Click-jacking"......who exactly is expected to understand that?
in Builder speak :
"Hey [builder guy], some of the untrusted input, which you render back to the user. This can cause a client side security issue. You need to encode all input from untrusted sources so the browser does not mistake it as code.
You also have a similar issue on your data layer. you need to parameterize untrusted input so it is not confused as code and executes resulting in unexpected issues.
You have some logical issues in relation to how browsers work where requests can be sent on your behalf by using your session, also best not to let your site be iFramed unless you intend it to be this way as it can be used to dupe your clients into doing things they never intended to do."
- which is easier to understand (assuming you are not a security expert)?
Well said, I prefer builder-speak when talking to developers. You might as well speak French while in Paris, right?
ReplyDelete