![SQL Injection Example
• An example Product Search input in a form: ‘something‘ OR ‘x’ = ‘x’
• This input is put directly into the SQL statement within the Web
application:
• $query = “SELECT prodinfo FROM prodtable WHERE prodname = ‘” .
$_POST[‘prod_search’] . “’”;
• Creates the following SQL:
• SELECT prodinfo FROM prodtable WHERE prodname = ‘something‘ OR
‘x’ = ‘x’
• Attacker has now successfully caused the entire database to be returned.](https://image.slidesharecdn.com/7a-190819093354/85/Web-application-security-part-01-5-320.jpg)
![Cross-Site Request Forgery[1]
• Cross-Site Request Forgery (CSRF) is an attack where a malicious
website will send a request to a web application that a user is already
authenticated against from a different website. This way an attacker
can access functionality in a target web application via the victim's
already authenticated browser. Targets include web applications like
social media, in-browser email clients, online banking and web
interfaces for network devices.](https://image.slidesharecdn.com/7a-190819093354/85/Web-application-security-part-01-14-320.jpg)
![Persistent XSS [2]
• The attacker uses one of the website's forms to insert a malicious
string into the website's database
• The victim requests a page from the website
• The website includes the malicious string from the database in the
response and sends it to the victim
• The victim's browser executes the malicious script inside the
response, sending the victim's cookies to the attacker's server](https://image.slidesharecdn.com/7a-190819093354/85/Web-application-security-part-01-28-320.jpg)
![Reflected XSS [2]
• The attacker crafts a URL containing a malicious string and sends it to
the victim
• The victim is tricked by the attacker into requesting the URL from the
website
• The website includes the malicious string from the URL in the
response
• The victim's browser executes the malicious script inside the
response, sending the victim's cookies to the attacker's server](https://image.slidesharecdn.com/7a-190819093354/85/Web-application-security-part-01-30-320.jpg)
![DOM-based XSS [2]
• The attacker crafts a URL containing a malicious string and sends it to
the victim
• The victim is tricked by the attacker into requesting the URL from the
website
• The website receives the request, but does not include the malicious
string in the response
• The victim's browser executes the legitimate script inside the
response, causing the malicious script to be inserted into the page
• The victim's browser executes the malicious script inserted into the
page, sending the victim's cookies to the attacker's server](https://image.slidesharecdn.com/7a-190819093354/85/Web-application-security-part-01-32-320.jpg)
![References
[1] https://www.veracode.com/security/csrf
[2] Jakolb Kallin, Irene Lobo Valbuena, Excess XSS, https://excess-
xss.com/](https://image.slidesharecdn.com/7a-190819093354/85/Web-application-security-part-01-63-320.jpg)
Web application security part 01
- 2. Contents • SQL Injection: Attacks and Defenses • Cross Site request forgery: Attacks and Defenses • Cross-site Scripting: Attacks and Defenses • Generating and storing session tokens
- 3. Database • Database = collection of data + set of rules that specify certain relationships among the data. • Data is stored in one or more files • The database file consists of records, which in turn consists of fields or elements. • Data can be organized in tables. All columns are given names, which are the attributes of the database. • A relation is a set of columns • Data is extracted from the database with the help of queries. • SQL is a Structured query language that specifies the rules of queries. One famous example is MySQL
- 4. SQL Injection: What is it? • Many web applications take user input from a form • Often this user input is used literally in the construction of a SQL query submitted to a database: • SELECT productdata FROM table WHERE productname = ‘user input product name’; • A SQL injection attack involves placing SQL statements in the user input
- 5. SQL Injection Example • An example Product Search input in a form: ‘something‘ OR ‘x’ = ‘x’ • This input is put directly into the SQL statement within the Web application: • $query = “SELECT prodinfo FROM prodtable WHERE prodname = ‘” . $_POST[‘prod_search’] . “’”; • Creates the following SQL: • SELECT prodinfo FROM prodtable WHERE prodname = ‘something‘ OR ‘x’ = ‘x’ • Attacker has now successfully caused the entire database to be returned.
- 6. SQL Injection Example • What if the attacker had instead entered: • something‘; DROP TABLE prodinfo; -- • Results in the following SQL: • SELECT prodinfo FROM prodtable WHERE prodname = ‘something’; DROP TABLE prodinfo; --’ • The comment symbol(--) consumes the final quote • Causes the entire database to be deleted • Depends on knowledge of table name • This is sometimes exposed to the attacker in debug code called during a database error event that is when the table name is not correctly specified • Using non-obvious table names would be a good practice
- 7. SQL Injection Possibilities • Using SQL injections, attackers can: • Add new data to the database • Could be destructive to find new records in a student database • Perform an INSERT in the injected SQL • Modify data currently in the database • Could be very costly to have an expensive item suddenly be deeply ‘discounted’ • Perform an UPDATE in the injected SQL • Often can gain access to other user’s system capabilities by obtaining their password
- 8. SQL Injection: More Examples 1 • Unauthorized Access Attempt: • password = ’ or 1=1 -- • SQL statement becomes: • select count(*) from users where username = ‘user’ and password = ‘’ or 1=1 - - • Checks if password is empty OR 1=1, which is always true, permitting access.
- 9. SQL Injection: More Examples 2 • Database Modification Attack: • password = foo’; delete from table users where username like ‘% • Database executes two SQL statements: • select count(*) from users where username = ‘user’ and password = ‘foo’ • delete from table users where username like ‘%’
- 10. SQL Injection: Impact • Yahoo! Voices was hacked in July. The attack acquired 453,000 user email addresses and passwords. The perpetrators claimed to have used union-based SQL injection to break in. • LinkedIn.com leaked 6.5 million user credentials in June. A class action lawsuit alleges that the attack was accomplished with SQL injection. • SQL injection was documented as a security threat in 1998, but new incidents still occur every month. Making honest mistakes, developers fail to defend against this means of attack, and the security of online data is at risk due to this.
- 11. SQL Injection: Defense • Use provided functions for escaping strings • Many attacks can be thwarted by simply using the SQL string escaping mechanism • ‘ ’ and “ ” • mysql_real_escape_string() is the preferred function for this • Unfortunately this is not a complete solution. Consider: • SELECT fields FROM table WHERE id = 23 OR 1=1 • No quotes are used here.
- 12. SQL Injection: Defense • Check syntax of input for validity • Many classes of input have fixed languages • Email addresses, dates, part numbers, etc. • Verify that the input is a valid string in the language • Sometime languages allow problematic characters (e.g., ‘*’ in email addresses); may decide to not allow these • If we can exclude quotes and semicolons that’s good • Not always possible: consider the name Bill O’Reilly • Want to allow the use of single quotes in names • Have length limits on input • Many SQL injection attacks depend on entering long strings
- 13. SQL Injection: Defense • Scan query string for undesirable word combinations that indicate SQL statements • INSERT, DROP, etc. • If we catch these, it can be checked against SQL syntax to see if they represent a statement or valid user input • Limit database permissions and segregate users • If we’re only reading the database, connect to database as a user that only has read permissions • Never connect as a database administrator in our web application
- 14. Cross-Site Request Forgery[1] • Cross-Site Request Forgery (CSRF) is an attack where a malicious website will send a request to a web application that a user is already authenticated against from a different website. This way an attacker can access functionality in a target web application via the victim's already authenticated browser. Targets include web applications like social media, in-browser email clients, online banking and web interfaces for network devices.
- 15. CSRF: Key Concepts • Malicious requests are sent from a site that a user visits to another site that the attacker believes the victim is validated against. • The malicious requests are routed to the target site via the victim’s browser, which is authenticated against the target site. • The vulnerability lies in the affected web application, not the victim’s browser or the site hosting the CSRF.
- 16. CSRF: Example 1 • In a Cross-Site Request Forgery attack, the attacker is exploiting how the target web application manages authentication. For CSRF to be exploited, the victim must be authenticated against (logged into) the target site. • For instance, let’s say examplebank.com has online banking that is vulnerable to CSRF. If we visit a page containing a CSRF attack on examplebank.com but am not currently logged in, nothing happens. If we are logged in, however, the requests in the attack will be executed as if they were actions that we had intended to take.
- 17. CSRF: Example 1 • First, let’s assume that we are logged into our account on examplebank.com, which allows for standard online banking features, including transferring funds to another account. • Now let’s say we happen to visit somemalicioussite.com. • It just so happens that this site is trying to attack people who bank with examplebank.com and has set up a CSRF attack on its site. • The attack will transfer $1,500.00 to account number 123456789.
- 18. CSRF: Example 1 • Somewhere on somemalicioussite.com, attackers have added this line of code: • <iframe src="//www.veracode.com/%3Ca%20href%3D"http://examplebank.com/app/tr ansferFunds?amount=1500&destinationAccount=123456789">http://example bank.com/app/transferFunds?amount=1500&destinationAccount=..." > • Upon loading that iframe, my browser will send that request to examplebank.com, which my browser has already logged in as me. The request will be processed and send $1,500.00 to account 123456789.
- 19. CSRF: Example 2 • Let’s assume we bought a new home wireless router. Like most wifi routers, it’s configured through a web interface. The router was shipped to us with an internal IP address of 192.168.1.1. • Lets assume we are having trouble configuring the router though, and fortunately the attackers over at somemalicioussite.com have published a guide that shows us exactly what buttons to click in the router interface to get everything set up securely. • The attackers have also set up a proxy server at 123.45.67.89 that will log all traffic that goes through it and look for things like passwords and session tokens.
- 20. CSRF: Example 2 • As we clicked through the configuration guide, lets assume we missed the 1x1 pixel image that failed to load: • <img src=”http://192.168.1.1/admin/config/outsideInterface?nexthop=123.45.67.89” alt=”pwned” height=”1” width=”1”/> • The attackers knew that when we were reading their tutorial, we would be logged into the router interface. So they had the CSRF attack set up in the tutorial. • With that request, our router would be reconfigured so that our traffic will be routed to their proxy server where they can do all manner of bad things with it.
- 21. CSRF: Defense • The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append CSRF tokens to each request and associate them with the user’s session. • Such tokens should at a minimum be unique per user session, but can also be unique per request. • By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user.
- 22. CSRF: Defense • The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user. • Without such an unpredictable token, attackers can forge malicious requests. • Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.
- 23. Cross-Site Sctipting • Cross Site Scripting (XSS) is a type of web application attack where malicious client-side script is injected into the application output and subsequently executed by the user’s browser. • The objective is to trick the client browser to execute malicious scripting commands • Caused by insufficient input validation • Javascript is the most popular scripting technology exploited
- 24. Javascript • Starts and ends with <script> tag • Javascript has access to cookies using document.cookie • Javascript can send HTTP requests to any destination by using XMLHttpRequest • Javascript can make arbitrary modifications to the HTML of current page by using DOM manipulation methods
- 25. Risks of Javascript (Malicious) • Cookie theft • Keylogging / Spying • Phishing Similarity: The attacker has injected code into a page served by the website
- 26. Basic XSS Model • Input: <script>….</script> • Output: • <html>Latest comment: <script>...</script> </html> print "<html>" print "Latest comment:" print database.latestComment print "</html>
- 27. Types of XSS • Persistent • Reflected • DOM - Based
- 28. Persistent XSS [2] • The attacker uses one of the website's forms to insert a malicious string into the website's database • The victim requests a page from the website • The website includes the malicious string from the database in the response and sends it to the victim • The victim's browser executes the malicious script inside the response, sending the victim's cookies to the attacker's server
- 30. Reflected XSS [2] • The attacker crafts a URL containing a malicious string and sends it to the victim • The victim is tricked by the attacker into requesting the URL from the website • The website includes the malicious string from the URL in the response • The victim's browser executes the malicious script inside the response, sending the victim's cookies to the attacker's server
- 32. DOM-based XSS [2] • The attacker crafts a URL containing a malicious string and sends it to the victim • The victim is tricked by the attacker into requesting the URL from the website • The website receives the request, but does not include the malicious string in the response • The victim's browser executes the legitimate script inside the response, causing the malicious script to be inserted into the page • The victim's browser executes the malicious script inserted into the page, sending the victim's cookies to the attacker's server
- 34. Some Statistics • These statistics only include media reported security incidents that can be associated with a web application security vulnerability Other / Unknown 39% SQL Injection 9% Credential / Session Prediction 9% Cross-Site Scripting 27% Insufficient Authorisation and Authenticatio n 16% ATTACK STATISTICS Source: www.webappsec.org
- 35. Famous XSS Attacks • Myspace Hack Spreading Date: 16 July 2006 WASC Threat Classification: Cross-site Scripting, Worm Myspace seemed to be a heaven for XSS worms. This one seems to be even more interesting as it uses JavaScript embedded in a flash file.
- 36. Famous XSS Attacks • google XSS Date: 04 July 2006 WASC Threat Classification: Cross-site Scripting An XSS vulnerability in the feature allowing adding an arbitrary RSS to personal web pages. Since this page resides on the main www.google.com host, the executed JavaScript can access any google resource
- 37. Famous XSS Attacks • PayPal Flaw Date: 16 June 2006 WASC Threat Classification: Cross-site Scripting While XSS vulnerabilities in public web sites are found daily, this one is of special interest. It was found in one of the sites most targeted by Phishers, it is exploitable for Phishing and was exploited. On top of that, it seems to have been discovered and reported to PayPal already two years ago but ignored due to a communication failure
- 38. XSS Attack Vectors • Injecting through (html) form inputs • URL injection (URL sent by e-mail or IM to the victim, or posted on public sites)
- 39. Persistent XSS Example • XAMPP server running apache. A PHP example site is loaded. • Functionality to add comments is provided • The comments are then stored in a mysql database and then displayed at comments.php
- 47. Reflected XSS Example • XAMPP server running apache. A PHP example site is loaded. • An attractive link is shown which contains a script • It gets bounced back from the server once the user clicks on the link
- 50. DOM Based XSS Example • This runs when the interpreter cannot find the img tag and runs the onerror script. There is no requirement of a server in this scenario file:///C:/Users/Admin/Desktop/xss.html#<img src="blah" onerror="alert('XSS!!');">
- 52. Defense Strategies Almost all scripts use <> () {} “ ‘ ; / • Encoding: Escape user input so that the browser interprets it only as data • Validation: Filter input so that all malicious parts of it are removed
- 53. Ideas to Bypass Input Verification • Even web applications which validate user inputs can be the target of XSS attacks. Some strategies to bypass such checks • <div style="background:url('javascript:alert(1)')"> javascript is accepted in CSS • <div style="background:url('javanscript:alert(1)')"> If the keyword “javascript” is filtered out, we can try to write it as follows. • alert(eval('document.body.inne' + 'rHTML')); If keywords representing “useful” javascript methods are filtered out, we can use the powerful eval() function to interpret a concatenation of string.
- 54. Session Tokens • A session identifier, session ID or session token is a piece of data that is used in network communications (often over HTTP) to identify a session, a series of related message exchanges. • Session identifiers become necessary in cases where the communications infrastructure uses a stateless protocol such as HTTP. • A session ID is typically granted to a visitor on their first visit to a site. • It is different from a user ID in that sessions are typically short-lived and may become invalid after a certain goal has been met.
- 55. Cookies • A cookie is a small text file that contains a small amount of information about a user visiting a site and is stored on the site visitor's computer by their browser. • Because the cookie is stored on the user’s computer, it does not require any server space no matter how many users you have. • We can use cookies to save user preferences, customize data, remember the last visit, or to keep track of items in an order while a user browses.
- 56. Cookies • Cookies can only be read by the site that created them, or a site 'underneath' the site that created them. This prevents other websites from stealing cookies. • The cookie specification introduced by Netscape also places limits on cookies. These limits are: • 310 total cookies. • 4 kilobytes per cookie • 20 cookies per server or domain.
- 57. Types of Cookies • First Party Cookies are written by our site and can only be read by our site. • Third Party Cookies are created by advertising in our page that is loaded from a third party site. These can only be read by the advertising code on any site displaying the same ads. • Session Cookies are not actually written to a file but are stored in the browser itself. These cookies only last as long as the browser is open.
- 58. Sessions • Sessions are a combination of a server-side cookie and a client-side cookie. • Client-side cookie simply holds a value (session token) that uniquely identifies the client to the server, and corresponds to a data file on the server. • Thus, when the user visits the site, their browser sends the reference code to the server, which loads the corresponding data.
- 59. HTTP session token • A session token is a unique identifier that is generated and sent from a server to a client to identify the current interaction session. • The client usually stores and sends the token as an HTTP cookie and/or sends it as a parameter in GET or POST queries. • Session tokens are used so that the client only has to handle the identifier—all session data is stored on the server (usually in a database, to which the client does not have direct access) linked to that identifier.
- 60. HTTP session token • Examples of the names that some programming languages use when naming their HTTP cookie include • JSESSIONID (JSP) • PHPSESSID (PHP) • ASPSESSIONID (ASP)
- 61. Advantages of Sessions • The server-side cookie can contain very large amounts of data with no hassle - client-side cookies are limited in size • The client-side cookie contains nothing other than a small reference code - as this cookie is passed each time someone visits a page on our site, we are saving a lot of bandwidth by not transferring large client- side cookies around • Session data is much more secure - only we are able to manipulate it, as opposed to client-side cookies which are editable by all
- 62. Conclusion • It is also important to note that sessions only last till the user closes their browser, whereas cookies can be configured to last longer. • However, other than the above, there is not much difference between session data and cookie data for most purposes.
- 63. References [1] https://www.veracode.com/security/csrf [2] Jakolb Kallin, Irene Lobo Valbuena, Excess XSS, https://excess- xss.com/