Talk:Injection Prevention Cheat Sheet

From OWASP
Revision as of 07:40, 7 April 2010 by AlexanderMeisel (Talk | contribs)

Jump to: navigation, search

Following questions to the wiki as from 6-apr-10

(items are the headlines in the wiki page):

  • Introduction
we read: "... especially SQL Injection, ..."
Hmm, SQL Injection is #1 in OWASP top 10 2010 now, but XSS is famous and popular as SQL Injection.
Q: why is XSS missing?
  • A2:
we read: "An already productive application (with MVC architecture) ..."
Q: why is this restricted to MVC? I don't see any reason for that as OpenSource applications must not be MVC.
  • OS calls
I'd use the term OS Commanding
  • Rule #1 (Perform proper input validation):
Input validation is just half the truth, in most cases output validation, better: proper output encoding, needs to be done. Input validation only applies to the program/script code itself, like eval() calls.
A good description of the term and related terms can be found at: http://projects.webappsec.org/Improper-Input-Handling and http://projects.webappsec.org/Improper-Output-Handling
Q: why is output validation missing? It's important for XSS, SQLI, LDAP, XPath etc..
I agree that for this Cheat Sheet output validation is not important, but just using input validation may give (some people) a wrong sense of the problem. To be discussed.

Answers to questions and comments

  • XSS is missing because the injection prevention cheat sheet is for the OWASP TOP 10 (new) specially for A1 .. XSS has its own major A2
  • A2 ... comment taken ... MVC architecture is only mentioned as an example .. this statement needs to be clarified
  • OS calls vs. OS commanding .... Jim what is your take on this as an native American English speaker? I personally don't like words with ing .. so OS commands might be better!?!?!?
  • Output validation is related to the 'missing XSS topic' and that particular family of problems ... Output validation is mostly irrelevant for pure injection problems (excluding XSS - Top10 A2 and XSRF - Top10 A5)

Missing, somehow in wiki as from 6-apr-10

  • Forms of Injection
I'm missing XSS. According the other headlines in this section, it proably should be named Content Spoofing and/or Client-side Injection.
Also think about AJAX (JSON) injection also (the client-side impact).
  • Application Protocol
The application protocol, HTTP here, can also be injected. Think of %0d%0a injections in the URL. This may lead to all sorts of HRS (HTTP Response Splitting/Smuggling, HTTP Request Smuggling/Splitting). It may also lead to HTTP header injections for example setting cookies.
  • File Include - RFI, LFI
Most web application frameworks support file inclusion, wether they are additional script code or some data. Improper data validation may lead to include program code or data from unexpected sources. Most common are vulneranilities in PHP. But SSI and even Java may be vulnerable.
  • Format String
If unvalidated user data are used as input to formatting strings, for example in C/C++ functions like fprintf, printf, sprintf, ..., arbitrary code may be executed or software crashes.
  • Null Byte Injection
This injection can alter intended application logic and allow malicious code injected. It can also be used to bypass sanity checks or filters in web applications or WAFS by adding URL-encoded null byte characters: %00.
  • URL Redirector Abuse
Bug or feature? It's an injection vulnerability, somehow.
Not sure if it should be added.
  • Web Services
Beside the already mentioned XPath and XML injection, there is SOAP, REST, Schema Injection and Routing Detour (probably some more, not sure about all the proper terms used here).