Andrews whitakrer lecture18-security.ppt

1
CSE 403
Web Security Testing
Reading:
Andrews/Whitaker, How to Break Web Software, Ch. 2-5
These lecture slides are copyright (C) Marty Stepp, 2007. They may not be rehosted, sold, or
modified without expressed permission from the author. All rights reserved.

2
Big questions
 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?

3
Denial-of-Service (DoS)
 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 $$$.

4
Packet sniffing
 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

5
Password cracking
 password cracking: Guessing the passwords of
privileged users of your system.
 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.

6
Phishing / social engineering
 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.

7
Man-in-the-middle
 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

8
Privilege escalation
 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...

9
Cross-site scripting (XSS)
 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.
 Attacker finds unsecure code on target site.
 Attacker uses hole to inject JavaScript into the page.
 User visits page, sees malicious script code.

10
SQL Injection
 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!

11
Thinking like an attacker:
Finding vulnerabilities

12
Panning for gold
 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

13
Input forms
 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...

14
Form validation
 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

15
User input attacks
 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

16
Guessing files/directories
 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

17
Other attacks
 Attacking GET parameters
 Attacking hidden input fields
 Attacking cookies
 Injecting malicious script code (XSS)
 Injecting malicious SQL queries (SQL injection)

19
Methods of security
 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."

20
Secure authentication
 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.

21
Principle of least privilege
 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

22
Sanitizing inputs
 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.

23
Verifying that code is secure
 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

24
Security audits
 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

25
Security audit questions
 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?

Andrews whitakrer lecture18-security.ppt

More Related Content

Similar to Andrews whitakrer lecture18-security.ppt (20)

Recently uploaded (20)

Andrews whitakrer lecture18-security.ppt