Security for Web Applications

1
Big questions 2

• How much do I have to worry about security in my

web application?

• What kinds of common attacks can be performed?

• What common bugs in my code lead to these flaws?

• What tools do attackers use?

• How can I prevent security problems in my code

and (hopefully) ensure overall system security?
Denial-of-Service (DoS) 3

• Denial of Service (DoS) attack:

Attacker causes web server to be unavailable.

• How attack is performed:

• Attacker frequently requests many pages from your web site.
• distributed DoS (DDoS): DoS using lots of computers
• Your server cannot handle this many requests at a time, so it
turns into a smoldering pile of goo (or just becomes very slow).

• Problems that this attack can cause:

• Users cannot get to your site.
• Online store's server crashes -> store loses potential revenue.
• Server may crash and lose or corrupt important data.
• All the bandwidth used by the DoSers may cost you $$$.
Packet sniffing 4

• packet sniffing: Listening to traffic sent on a network.

• Many internet protocols (http, aim, email) are unsecure.
• If an attacker is on the same local network (LAN) as you, he
may be able to listen to information your computer is
sending.
• read your email/IMs as you send them
• see what web sites you are viewing
• grab your password as it's being sent to the server

• solutions:
• Use secure protocols (https)
• Encryption
• Don't let creeps on your LAN
Password cracking 5

• password cracking: Guessing the passwords of

privileged users of your system.

• How attack is performed:

• brute force attack: Attacker uses software that sequentially
tries every possible password.
• dictionary attack: Attacker uses software that sequentially
tries passwords based on words in a dictionary.
• every word in the dictionary
• combinations of words, numbers, etc.

• What you can do about it:

• Force users to have secure passwords.
• Block an IP address from logging in after N failed attempts.
 Phishing / social engineering 6
• phishing: Masqueraded mails or web sites.
• social engineering: Attempts to manipulate users,
such as fraudulently acquiring passwords or credit card
numbers.

• Problems:
• If trusted users of your
system are tricked into
giving out their personal
information, attackers
can use this to log in as
those users and
compromise your system.
 Man-in-the-middle 7
• man-in-the-middle attack: Attacker sits
between two communication endpoints and
silently intercepts traffic between them.
• tricks user to go to attacker's site instead of real
site
• intercepts sensitive information and/or modifies
data before sending it from one endpoint to the
other
Privilege escalation 8

• privilege escalation: Attacker becomes able

to run code on your server as a privileged user.
• Example: Perhaps normal users aren't able to
directly query your database. But an attacker may
find a flaw in your security letting him run as an
administrator and perform the query.

• Once you're running as root, you're God.

You own the server.
You can do anything you want...
Cross-site scripting (XSS) 9

• cross-site scripting: Causing one person's

script code to be executed when a user
browses to another site.
• Example: Visit google.com, but evil.com's
JavaScript runs.

• How attack is performed:

• Attacker finds unsecure code on target site.
• Attacker uses hole to inject JavaScript into the
page.
• User visits page, sees malicious script code.
SQL Injection 10

• SQL injection: An attacker causing undesired SQL

queries to be run on a server's database.
• Often caused when untrusted input is pasted into a SQL
query
• Example:
• query="SELECT * FROM Users WHERE name=' +
name + "';";
• specify a user name of "haha' OR 'a'='a"
• SELECT * FROM Users WHERE
name='haha' OR 'a'='a';

• Attacker can see, delete, modify your sensitive

personal data!
Thinking like an attacker:
Finding vulnerabilities
11
Panning for gold 12

• Looking through a target application for exploits:

• View Source , and look for:
• HTML comments
• script code
• other sensitive information in code:
IP addresses, email addresses, SQL queries, hidden fields, ...

• watch HTTP requests/responses

• look for hidden pages, files, parameters to target

• error messages sent back to your browser by the app

• 200: OK
• 400: Invalid request
• 403: Forbidden
• 404: File not found
• 500: Internal server error
Input forms 13

• Forms let users pass parameters to the web server.

• Parameters are passed using GET or POST requests.

• GET: parameters are contained in the request URL.
http://www.google.com?q=Stephen+Colbert&lang=en
• POST: parameters are contained in the HTTP packet
header.
• harder for the user to see, but no more secure than GET

• Forms provide a rich ground

for us to attack...
Form validation 14

• validation: Examining form parameters to make sure

they are acceptable before they are submitted.
• nonempty, alphabetical, numeric, length, ...

• client-side: HTML/JS checks values before request is sent.

• server-side: JSP/Ruby/PHP/etc. checks values received.

• Some validation is performed by restricting the choices

available to the user.
• select boxes
• input text boxes with
maxlength attribute
• key event listeners that
erase certain key presses
User input attacks 15

• Bypassing client-side input restrictions and

validation
• maxlength limits on input text fields
• choices not listed in a select boxes
• hidden input fields
• modifying or disabling client-side JavaScript
validation code
Guessing files/directories 16

• Many sites have reachable files and resources that are

hidden from attackers only by obscurity

• Try common file/folder/commands to see what happens

• /etc/passwd , /etc/shadow
• cat, ls, grep
• guess file names based on others
• page11.php -->
page12.php
• loginfailure.jsp -->
loginsuccess.jsp
• accounts/myaccount.html -->
accounts/youraccount.html
• brute force / web spiders
• port scanners
Other attacks 17

• Attacking GET parameters

• Attacking hidden input fields

• Attacking cookies

• Injecting malicious script code (XSS)

• Injecting malicious SQL queries (SQL injection)

Designing for Security
18
Methods of security 19

• Security through obscurity: Relying on the fact

that attackers don't know something needed to
harm you.

• Example: "If an attacker pointed their browser to

http://foo.com/passwords.txt, they'd get our
passwords. But nobody knows that file is there, so we
are safe."

• Example: "Our authentication database goes down for

2 minutes every night at 4am. During that time any
user can log in without restrictions. But no one knows
this, and the odds of a login at that time are
miniscule."
Secure authentication 20

• Force users to log in to your system before

performing sensitive operations

• Use secure protocols (https, etc.) to prevent

sniffing

• Force users to use strong passwords

• not "password", "abc", same as user name, etc.
Principle of least privilege 21

• principle of least privilege: Having just enough

authority to get the job done (and no more!).

• Examples:
• A web server should only be given access to the set of
HTML files that the web server is supposed to serve.
• Code should not "run as root" or as a highly privileged
user unless absolutely necessary.

• Turn off unnecessary services on your web server

• disable SSH, VNC, sendmail, etc.
• close all ports except 80, others needed for web traffic
Sanitizing inputs 22

• sanitizing inputs: Encoding and filtering

untrusted user input before accepting it into a
trusted system.
• Ensure that accepted data is the right type, format,
length...
• Disallow entry of bad data into an HTML form.
• Remove any SQL code from submitted user names.
• HTML-encode any input text that is to be displayed
back to the user as HTML or JavaScript.
Verifying that code is secure 23

• Before code is written:

• considering security in the design process

• As code is being written:

• code reviews
• pair programming

• After code has been written:

• walkthroughs
• security audits
Security audits 24

• security audit: Series of checks and questions to

assess the security of your system
• can be done by an internal or external auditor
• best if done as a process, not an individual event

• penetration test: Targeted white-hat attempt to

compromise your system's security
• not unlike our attempts to break CSE 144's turnin page

• risk analysis: Assessment of relative risks of what

can go wrong when security is compromised
Security audit questions 25

• Does your system require secure authentication with passwords?

• Are passwords difficult to crack?

• Are there access control lists (ACLs) in place on network devices?

• Are there audit logs to record who accesses data?

• Are the audit logs reviewed?

• Are your OS security settings up to accepted industry levels?

• Have all unnecessary applications and services been eliminated?

• Are all operating systems and applications patched to current levels?

• How is backup media stored? Who has access to it? Is it up-to-date?

• Is there a disaster recovery plan? Has it ever been rehearsed?

• Are there good cryptographic tools in place to govern data encryption?

• Have custom-built applications been written with security in mind?

• How have these custom applications been tested for security flaws?

• How are configuration and code changes documented at every level? How are these records reviewed and who conducts the
review?