This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Talk:Injection Prevention Cheat Sheet"

From OWASP
Jump to: navigation, search
(AJAX added)
(Web Services)
Line 41: Line 41:
 
: Bug or feature? It's an injection vulnerability, somehow.
 
: Bug or feature? It's an injection vulnerability, somehow.
 
: Not sure if it should be added.
 
: 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).

Revision as of 06:01, 7 April 2010

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.

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).