Web Security: SQL Injection
Professor : Dr. Eduard Babulak
Students : Vortana SAY
Budi Chandra
Stephane Moluh
1
Maharishi University of Management
Department of Computer Science
Computer Professional Program
Computer Security: CS466
February Entry, 2015
Outline
1. Introduction
1. Objective of the project
2. Introduction to SQL injection
2. Architecture of the simulation system
3. Implementation
1. Choice of the technologies
2. SQL injection attacks
3. Demonstration
4. SQL injection countermeasures
5. Demonstration
4. Best Practices
5. Conclusion
2
Outline
1. Introduction
1. Objective of the project
2. Introduction to SQL injection
2. Architecture of the simulation system
3. Implementation
1. Choice of the technologies
2. SQL injection attacks
3. Demonstration
4. SQL injection countermeasures
5. Demonstration
4. Best Practices
5. Conclusion
3
Objective of the project
4
•Provide the overview of SQL Injection.
•Examine various technical implementations of the
SQL injection.
•Countermeasures against the SQL injection.
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
Introduction to SQL injection
5
• SQL Injection is an attack where the user supplies input in order to
construct SQL request that will retrieve information from Database
[1].
• SQL injection is an attack in which the SQL code is inserted or
appended into application, or user input parameters that are later
passed to a back-end SQL server for parsing and execution [2].
• SQL injection is a code injection technique, used to attack data-driven
applications, in which malicious SQL statements are inserted into an
entry field for execution [3].
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
Introduction to SQL injection
6
SQL Injection attack illustrate [4]
3
Attacker sends data containing SQL fragments
Attacker enters SQL
fragments into a web page
that uses input in a query
1
Attacker views unauthorized data
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus.Functions
Database
2 Application sends
modified query to
database, which
executes it
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
Introduction to SQL injection
7
• Vulnerability detection on web application
• Everything between the <FORM> and </FORM> have
potential parameters that might be useful [5].
• Try to look especially for URL that takes parameters, like:
GET method, i.e.: http://test/index.php?id=10 [2].
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
Introduction to SQL injection
8
• Vulnerability detection on web application (Cont’)
• POST parameters can be injected using a traffic
manipulation tool or web browser plug-in [2].
• Using blind SQL injection to inject and analyse the error
message from database if any.
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
Introduction to SQL injection
9
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
Consequences [6]
Confidentiality SQL databases generally contains sensitive data, so loss of
confidentiality is a big problem.
Authentication If poor SQL commands are used to check user names and
passwords, authentication can be compromised.
Authorization If authorization information is held in a SQL database, it can
be exploited.
Integrity SQL Injection attack can change or delete data.
Introduction to SQL injection
10
• Examples [7]
COMPANY DATE RESULTS
Mapp.nl (Online store) 2015 157,000 email addresses and passwords
were stolen
US Federal (Army, NASA, ...) 2013 More than 100,000 user information
Yahoo 2012 450,000 plain text passwords
Ingenicard 2012 estimated financial fraud losses $9 million
Global Payments 2011 950,000 card numbers stolen estimated loss
$92.7 million
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
Outline
1. Introduction
1. Objective of the project
2. Introduction to SQL injection
2. Architecture of the simulation system
3. Implementation
1. Choice of the technologies
2. SQL injection attacks
3. Demonstration
4. SQL injection countermeasures
5. Demonstration
4. Best Practices
5. Conclusion
11
Architecture of the simulation system
12
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
Architecture of the simulation system
13
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
Outline
1. Introduction
1. Objective of the project
2. Introduction to SQL injection
2. Architecture of the simulation system
3. Implementation
1. Choice of the technologies
2. SQL injection attacks
3. Demonstration
4. SQL injection countermeasures
5. Demonstration
4. Best Practices
5. Conclusion
14
Choice of Technologies
15
Web Server LAMP (Linux, Apache, MySQL, PHP)
Web Client side
HTML (Hyper Text Markup Language)
CSS (Cascading Style Sheets)
Bootstrap
Server side
PHP
Tools Web browser: Firefox
Integrated Development Environment (IDE): Netbeans
OS Ubuntu 14.10
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
SQL injection attacks
16
1. Incorrectly filtered escape characters
2. Incorrect type handling
3. Second Order SQL Injection
4. Blind SQL Injection
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
SELECT id FROM users WHERE username = ‘$_GET[usrname]’ AND
password = ‘$_GET[psw]’;
SELECT id FROM users WHERE username = ‘’OR ‘1’ = ‘1’ AND
password = ‘’OR ‘1’ = ‘1’;
SQL injection attacks
17
1. Incorrectly filtered escape characters
• When the user input is not filter for escape characters
Example:
SQL Injection
SQL Injection
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
SQL injection attacks
18
2. Incorrect type handling
• When an input is not appropriately typed or is not checked for type constraints.
Example:
Query:
“SELECT * FROM usersInfo WHERE id= ”.$_GET[“var_number_id”].“;”
SQL Injection:
1;DROP TABLE users
Interpreted query:
SELECT * FROM usersInfo WHERE id=1;DROP TABLE users;
SQL Injection
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
SQL injection attacks
19
3. Second Order SQL Injection
• When the submitted values contain SQL injection are stored in database
(not yet executed immediately).
• Normally developer trust the data from database.
• SQL injection retrieve from database might be executed by another part of
that application without controls to protect against SQL injection.
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
SQL injection attacks
20
4. Blind SQL Injection
• When the web application is vulnerable to an SQL injection,
but the results of the injection are not known to the attacker.
• No output from verbose database error messages or in-band
data concatenation.
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
SQL injection attacks
21
4. Blind SQL Injection (Cont’)
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
• Slight changes are visible in the
resulting page.Partially
• they do not produce difference in
output so, it is harder to determine if
an injection does take place.
Totally
SQL injection attacks
22
3. Blind SQL Injection (Cont’)
• SQLMap is an open source testing tool
• Automates the process of detecting and exploiting SQL injection flaws
• Taking over of database servers
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
SQLMap tool [8]
23
Demonstration
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
SQL Injection countermeasures
24
1. Hexadecimal Conversion
2. Database permission
3. Pattern check
4. Escaping
5. Parameterized statements
Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system
SQL injection countermeasures
25
1. Hexadecimal Conversion
PHP Functions:
• DECHEX — Decimal to hexadecimal [9].
• BIN2HEX — Convert any other type of variable into hex [9].
MySQL Function:
• UNHEX — Return a string containing hex representation of a number [10].
Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system
Example
"SELECT * FROM user WHERE `usrname`= UNHEX(".bin2hex($userInput).")";
SQL injection countermeasures
26
2. Securing Database
• Well-defined user role membership and provide only needed
privileged
• Segregated (separate) Database login
• Revoke public permission
• Use strong cryptography to protect stored sensitive data
Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system
SQL injection countermeasures
27
3. Pattern check: Input validation using regular expression
• Whitelist
the practice of only accepting input that is known to be good
• Blacklisting
the practice of only rejecting input that is known to be bad
Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system
SQL injection countermeasures
28
3. Pattern check: Input validation using regular expression
• Whitelist (points should be considered)
• Known value
• Data type
• Data size
• Data range
• Data content
Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system
Example for data content:
US Zip code: ^d{5}(-d{4})?$
SQL injection countermeasures
29
3. Pattern check: Input validation using regular expression
• Blacklisting
Reject input that contains malicious content
Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system
Example of known bad character, string or pattern:
[(' OR)|('(''|[^'])*')|(;)|((ALTER|CREATE|DELETE|DROP|EXEC(UTE){0,1}|INSERT(
+INTO){0,1}|MERGE|SELECT|UPDATE|UNION( +ALL){0,1}))]
SQL injection countermeasures
30
4. Escaping
Escape characters that have special meaning in SQL.
Example of forming a valid SQL string literal:
• A single quote (‘) in a parameter two single quotes (‘’)
• Escaped using back slash(’)
Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system
SQL injection countermeasures
31
5. Parameterized statements
• Differentiate between SQL statements and data.
• Used parameters which act exactly like a placeholders or
bind variables.
• Website only send the data to replace the placeholders.
Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system
Example:
if (!($stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (?)"))) {
echo "Prepare failed: (" . $mysqli->errno . ") " . $mysqli->error;
}
32
Demonstration
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
Outline
1. Introduction
1. Objective of the project
2. Introduction to SQL injection
2. Architecture of the simulation system
3. Implementation
1. Choice of the technologies
2. SQL injection attacks
3. Demonstration
4. SQL injection countermeasures
5. Demonstration
4. Best Practices
5. Conclusion
33
Best Practices
34
1. Code-level defenses
• Data sanitization
• Data validation
• Trust no one (data from either users or database)
2. Platform-level defenses
• Secure database
• Change password of the super users regularly
• Web Application Firewall
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
Outline
1. Introduction
1. Objective of the project
2. Introduction to SQL injection
2. Architecture of the simulation system
3. Implementation
1. Choice of the technologies
2. SQL injection attacks
3. Demonstration
4. SQL injection countermeasures
5. Demonstration
4. Best Practices
5. Conclusion
35
Conclusion
36
• SQL Injection is a dangerous vulnerability
• Transform a normal SQL calls to a malicious calls
• Leads to unauthorized access, change or delete data and data
stolen
• All programming languages and all SQL databases are
potentially vulnerable
• Do not take SQL injection for granted !!
Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
REFERENCES
37
[1] William Stalling, Computer Security Principles and Practice. United
State of America: Pearson Education, 2012, 364.
[2] Justin Clarke, SQL Injection Attacks and Defense. United State of
America: Elsevier, 2012, 22.
[3] [online] 2000, http://en.wikipedia.org/wiki/SQL_injection (Accessed:
15 April 2015).
[4] M. Morana, “OWASP Top And Insecure Software Root Causes,"
[online] 2008, http://fr.slideshare.net/marco_morana/owasp-top-10-
and-insecure-software-root-causes-presentation (Accessed: 20 April
2015).
REFERENCES
38
[5] [online]
2002, http://www.securiteam.com/securityreviews/5DP0N1P76E.h
tml (Accessed: 20 April 2015).
[6] [online] 2014, https://www.owasp.org/index.php/SQL_Injection
(Accessed: 14 April 2015).
[7] Ranger78, “SQL INJECTION HALL OF SHAME" [online],
http://codecurmudgeon.com/wp/sql-injection-hall-of-shame/
(Accessed: 20 April 2015).
REFERENCES
39
[8] [online] 2006-2015, http://sqlmap.org/ (Accessed: 20 April 2015).
[9] [online] 2001-2015, http://php.net/manual/en/index.php
(Accessed: 20 April 2015).
[10] [online] 2015, https://dev.mysql.com/doc/refman/5.0/en/string-
functions.html (Accessed: 20 April 2015).
Thank for your attention
Q & A
40

Web Security: SQL Injection

  • 1.
    Web Security: SQLInjection Professor : Dr. Eduard Babulak Students : Vortana SAY Budi Chandra Stephane Moluh 1 Maharishi University of Management Department of Computer Science Computer Professional Program Computer Security: CS466 February Entry, 2015
  • 2.
    Outline 1. Introduction 1. Objectiveof the project 2. Introduction to SQL injection 2. Architecture of the simulation system 3. Implementation 1. Choice of the technologies 2. SQL injection attacks 3. Demonstration 4. SQL injection countermeasures 5. Demonstration 4. Best Practices 5. Conclusion 2
  • 3.
    Outline 1. Introduction 1. Objectiveof the project 2. Introduction to SQL injection 2. Architecture of the simulation system 3. Implementation 1. Choice of the technologies 2. SQL injection attacks 3. Demonstration 4. SQL injection countermeasures 5. Demonstration 4. Best Practices 5. Conclusion 3
  • 4.
    Objective of theproject 4 •Provide the overview of SQL Injection. •Examine various technical implementations of the SQL injection. •Countermeasures against the SQL injection. Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 5.
    Introduction to SQLinjection 5 • SQL Injection is an attack where the user supplies input in order to construct SQL request that will retrieve information from Database [1]. • SQL injection is an attack in which the SQL code is inserted or appended into application, or user input parameters that are later passed to a back-end SQL server for parsing and execution [2]. • SQL injection is a code injection technique, used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution [3]. Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 6.
    Introduction to SQLinjection 6 SQL Injection attack illustrate [4] 3 Attacker sends data containing SQL fragments Attacker enters SQL fragments into a web page that uses input in a query 1 Attacker views unauthorized data Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus.Functions Database 2 Application sends modified query to database, which executes it Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 7.
    Introduction to SQLinjection 7 • Vulnerability detection on web application • Everything between the <FORM> and </FORM> have potential parameters that might be useful [5]. • Try to look especially for URL that takes parameters, like: GET method, i.e.: http://test/index.php?id=10 [2]. Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 8.
    Introduction to SQLinjection 8 • Vulnerability detection on web application (Cont’) • POST parameters can be injected using a traffic manipulation tool or web browser plug-in [2]. • Using blind SQL injection to inject and analyse the error message from database if any. Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 9.
    Introduction to SQLinjection 9 Introduction ConclusionArchitecture of the simulation system Implementation Best Practices Consequences [6] Confidentiality SQL databases generally contains sensitive data, so loss of confidentiality is a big problem. Authentication If poor SQL commands are used to check user names and passwords, authentication can be compromised. Authorization If authorization information is held in a SQL database, it can be exploited. Integrity SQL Injection attack can change or delete data.
  • 10.
    Introduction to SQLinjection 10 • Examples [7] COMPANY DATE RESULTS Mapp.nl (Online store) 2015 157,000 email addresses and passwords were stolen US Federal (Army, NASA, ...) 2013 More than 100,000 user information Yahoo 2012 450,000 plain text passwords Ingenicard 2012 estimated financial fraud losses $9 million Global Payments 2011 950,000 card numbers stolen estimated loss $92.7 million Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 11.
    Outline 1. Introduction 1. Objectiveof the project 2. Introduction to SQL injection 2. Architecture of the simulation system 3. Implementation 1. Choice of the technologies 2. SQL injection attacks 3. Demonstration 4. SQL injection countermeasures 5. Demonstration 4. Best Practices 5. Conclusion 11
  • 12.
    Architecture of thesimulation system 12 Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 13.
    Architecture of thesimulation system 13 Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 14.
    Outline 1. Introduction 1. Objectiveof the project 2. Introduction to SQL injection 2. Architecture of the simulation system 3. Implementation 1. Choice of the technologies 2. SQL injection attacks 3. Demonstration 4. SQL injection countermeasures 5. Demonstration 4. Best Practices 5. Conclusion 14
  • 15.
    Choice of Technologies 15 WebServer LAMP (Linux, Apache, MySQL, PHP) Web Client side HTML (Hyper Text Markup Language) CSS (Cascading Style Sheets) Bootstrap Server side PHP Tools Web browser: Firefox Integrated Development Environment (IDE): Netbeans OS Ubuntu 14.10 Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 16.
    SQL injection attacks 16 1.Incorrectly filtered escape characters 2. Incorrect type handling 3. Second Order SQL Injection 4. Blind SQL Injection Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 17.
    SELECT id FROMusers WHERE username = ‘$_GET[usrname]’ AND password = ‘$_GET[psw]’; SELECT id FROM users WHERE username = ‘’OR ‘1’ = ‘1’ AND password = ‘’OR ‘1’ = ‘1’; SQL injection attacks 17 1. Incorrectly filtered escape characters • When the user input is not filter for escape characters Example: SQL Injection SQL Injection Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 18.
    SQL injection attacks 18 2.Incorrect type handling • When an input is not appropriately typed or is not checked for type constraints. Example: Query: “SELECT * FROM usersInfo WHERE id= ”.$_GET[“var_number_id”].“;” SQL Injection: 1;DROP TABLE users Interpreted query: SELECT * FROM usersInfo WHERE id=1;DROP TABLE users; SQL Injection Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 19.
    SQL injection attacks 19 3.Second Order SQL Injection • When the submitted values contain SQL injection are stored in database (not yet executed immediately). • Normally developer trust the data from database. • SQL injection retrieve from database might be executed by another part of that application without controls to protect against SQL injection. Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 20.
    SQL injection attacks 20 4.Blind SQL Injection • When the web application is vulnerable to an SQL injection, but the results of the injection are not known to the attacker. • No output from verbose database error messages or in-band data concatenation. Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 21.
    SQL injection attacks 21 4.Blind SQL Injection (Cont’) Introduction ConclusionArchitecture of the simulation system Implementation Best Practices • Slight changes are visible in the resulting page.Partially • they do not produce difference in output so, it is harder to determine if an injection does take place. Totally
  • 22.
    SQL injection attacks 22 3.Blind SQL Injection (Cont’) • SQLMap is an open source testing tool • Automates the process of detecting and exploiting SQL injection flaws • Taking over of database servers Introduction ConclusionArchitecture of the simulation system Implementation Best Practices SQLMap tool [8]
  • 23.
    23 Demonstration Introduction ConclusionArchitecture ofthe simulation system Implementation Best Practices
  • 24.
    SQL Injection countermeasures 24 1.Hexadecimal Conversion 2. Database permission 3. Pattern check 4. Escaping 5. Parameterized statements Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system
  • 25.
    SQL injection countermeasures 25 1.Hexadecimal Conversion PHP Functions: • DECHEX — Decimal to hexadecimal [9]. • BIN2HEX — Convert any other type of variable into hex [9]. MySQL Function: • UNHEX — Return a string containing hex representation of a number [10]. Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system Example "SELECT * FROM user WHERE `usrname`= UNHEX(".bin2hex($userInput).")";
  • 26.
    SQL injection countermeasures 26 2.Securing Database • Well-defined user role membership and provide only needed privileged • Segregated (separate) Database login • Revoke public permission • Use strong cryptography to protect stored sensitive data Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system
  • 27.
    SQL injection countermeasures 27 3.Pattern check: Input validation using regular expression • Whitelist the practice of only accepting input that is known to be good • Blacklisting the practice of only rejecting input that is known to be bad Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system
  • 28.
    SQL injection countermeasures 28 3.Pattern check: Input validation using regular expression • Whitelist (points should be considered) • Known value • Data type • Data size • Data range • Data content Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system Example for data content: US Zip code: ^d{5}(-d{4})?$
  • 29.
    SQL injection countermeasures 29 3.Pattern check: Input validation using regular expression • Blacklisting Reject input that contains malicious content Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system Example of known bad character, string or pattern: [(' OR)|('(''|[^'])*')|(;)|((ALTER|CREATE|DELETE|DROP|EXEC(UTE){0,1}|INSERT( +INTO){0,1}|MERGE|SELECT|UPDATE|UNION( +ALL){0,1}))]
  • 30.
    SQL injection countermeasures 30 4.Escaping Escape characters that have special meaning in SQL. Example of forming a valid SQL string literal: • A single quote (‘) in a parameter two single quotes (‘’) • Escaped using back slash(’) Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system
  • 31.
    SQL injection countermeasures 31 5.Parameterized statements • Differentiate between SQL statements and data. • Used parameters which act exactly like a placeholders or bind variables. • Website only send the data to replace the placeholders. Introduction Team and Planning ConclusionImplementationArchitecture of the simulation system Example: if (!($stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (?)"))) { echo "Prepare failed: (" . $mysqli->errno . ") " . $mysqli->error; }
  • 32.
    32 Demonstration Introduction ConclusionArchitecture ofthe simulation system Implementation Best Practices
  • 33.
    Outline 1. Introduction 1. Objectiveof the project 2. Introduction to SQL injection 2. Architecture of the simulation system 3. Implementation 1. Choice of the technologies 2. SQL injection attacks 3. Demonstration 4. SQL injection countermeasures 5. Demonstration 4. Best Practices 5. Conclusion 33
  • 34.
    Best Practices 34 1. Code-leveldefenses • Data sanitization • Data validation • Trust no one (data from either users or database) 2. Platform-level defenses • Secure database • Change password of the super users regularly • Web Application Firewall Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 35.
    Outline 1. Introduction 1. Objectiveof the project 2. Introduction to SQL injection 2. Architecture of the simulation system 3. Implementation 1. Choice of the technologies 2. SQL injection attacks 3. Demonstration 4. SQL injection countermeasures 5. Demonstration 4. Best Practices 5. Conclusion 35
  • 36.
    Conclusion 36 • SQL Injectionis a dangerous vulnerability • Transform a normal SQL calls to a malicious calls • Leads to unauthorized access, change or delete data and data stolen • All programming languages and all SQL databases are potentially vulnerable • Do not take SQL injection for granted !! Introduction ConclusionArchitecture of the simulation system Implementation Best Practices
  • 37.
    REFERENCES 37 [1] William Stalling,Computer Security Principles and Practice. United State of America: Pearson Education, 2012, 364. [2] Justin Clarke, SQL Injection Attacks and Defense. United State of America: Elsevier, 2012, 22. [3] [online] 2000, http://en.wikipedia.org/wiki/SQL_injection (Accessed: 15 April 2015). [4] M. Morana, “OWASP Top And Insecure Software Root Causes," [online] 2008, http://fr.slideshare.net/marco_morana/owasp-top-10- and-insecure-software-root-causes-presentation (Accessed: 20 April 2015).
  • 38.
    REFERENCES 38 [5] [online] 2002, http://www.securiteam.com/securityreviews/5DP0N1P76E.h tml(Accessed: 20 April 2015). [6] [online] 2014, https://www.owasp.org/index.php/SQL_Injection (Accessed: 14 April 2015). [7] Ranger78, “SQL INJECTION HALL OF SHAME" [online], http://codecurmudgeon.com/wp/sql-injection-hall-of-shame/ (Accessed: 20 April 2015).
  • 39.
    REFERENCES 39 [8] [online] 2006-2015,http://sqlmap.org/ (Accessed: 20 April 2015). [9] [online] 2001-2015, http://php.net/manual/en/index.php (Accessed: 20 April 2015). [10] [online] 2015, https://dev.mysql.com/doc/refman/5.0/en/string- functions.html (Accessed: 20 April 2015).
  • 40.
    Thank for yourattention Q & A 40

Editor's Notes

  • #7 http://me5145.blogspot.com/2014_09_01_archive.html
  • #22 Partially Blind Injections In the resulting page slight changes are visible, for example, one can be redirected to the main page when the injection is unfruitful, whereas the fruitful one will return a blank page. Totally Blind Injections As for the totally one, they do not produce difference in output of any kind. Hence, it is harder to determine whether an injection does take place. Conditional Responses The logical statement is evaluated by the database, on the side of the attacker
  • #23 Partially Blind Injections In the resulting page slight changes are visible, for example, one can be redirected to the main page when the injection is unfruitful, whereas the fruitful one will return a blank page. Totally Blind Injections As for the totally one, they do not produce difference in output of any kind. Hence, it is harder to determine whether an injection does take place. Conditional Responses The logical statement is evaluated by the database, on the side of the attacker
  • #27 Every database server platform has a default role to which every login belongs, usually called the public role, which has a default set of permissions that includes access to system objects.
  • #29 ^\d{5} Match exactly five numeric digits at the start of the string. (–\d{4})? Match the dash character plus exactly four digits either once (present) or not at all (not present). $ This would appear at the end of the string. If there is additional content at the end of the string, the regular expression will not match.
  • #30 This commonly involves rejecting input that contains content that is specifically known to be malicious by looking through the content for a number of “known bad” characters, strings, or patterns.