You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 3 Next »
TITULO
Injection
OWASP defines Injection flaws as follows:
A1:2017 – Injection
Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
Injection is a broad concept that covers many different security risks.
What’s common to all of them is that “interpreters” running in the app’s background can be intentionally cheated to run code that can be exploited by an attacker.
Depending on the underlying interpreter, injection flaws can occur on SQL-engines, LDAP engines, OS command-interpreters, XML interpreters, etc.
Tainted Data Flow
A common injection root cause is to send untrusted (potentially tainted) data to an interpreter as part of a command or query.
Source locations are those places in the code from where data comes in, that can be potentially controlled by the user (or the environment) and must consequently be presumably considered as tainted (as they may be used to build injection attacks).
- User input should always be considered as untrusted (you will have no way to know if a user is an attacker or a normal app user).
Sink locations are those places where consumed data must be untainted.
- Data used by any interpreter (a sink) must always be trusted (must not be controlled by a threat), i.e. sensitive data sinks rely on trusted (untainted) data
You app will contain an injection point (an injection vulnerability) wherever a data flow exists where any sink consumes input data which is not being properly neutralized. Kiuwan scans your source code to find any injection point:
For all possible sinks, prove that tainted data will never be used where untainted data is expected.
TITULO
- No labels