Download What is Software Security

August 1, 2006
The Software Security Problem
August 1, 2006
August 1, 2006
August 1, 2006
Traditional Security is Reactive
• Perimeter defense
(firewalls)
• Intrusion detection
• Over-reliance on
cryptography
• Penetrate and patch
• Penetration testing
August 1, 2006
The Problem is Software
“75 percent of hacks happen at the application.”
Theresa Lanowitz, Gartner Inc.
August 1, 2006
Hackers
“Malicious hackers don’t create security holes;
they simply exploit them. Security holes and
vulnerabilities – the real root cause of the
problem – are the result of bad software design
and implementation.”
John Viega & Gary McGraw
August 1, 2006
Developers Aren’t Ready
“64% of developers are not confident in their
ability to write secure applications”
Bill Gates, RSA 2005
August 1, 2006
A Growing Problem
Software Vulnerabilities
5690
6000
5000
4129
4000
3780
2003
2004
2437
3000
2000
3784
1090
1000
0
2000
August 1, 2006
2001
2002
2005
Penetrate and Patch
Discover flaws after deployment.
Often by attackers.
Users may not deploy patches.
Patches may have security flaws (15%?)
Patches are maps to vulnerabilities.
Attackers reverse engineer to create attacks.
August 1, 2006
Vulnerabilities and Threats
Vulnerability: A bug or flaw in a system that
makes an attack possible.
Threat: A party with the capability and intention
to exploit a vulnerability.
August 1, 2006
OWASP Top 10 Vulnerabilities
1. Unvalidated Input
– Information from web requests is not validated before
being used by a web application. Attackers can use these
flaws to attack backend components through a web
application.
2. Broken Access Control
– Restrictions on what authenticated users are allowed to do
are not properly enforced. Attackers can exploit these flaws
to access other users' accounts, view sensitive files, or use
unauthorized functions.
August 1, 2006
OWASP Top 10 Vulnerabilities
3. Broken Authentication and Session Management
– Account credentials and session tokens are not properly
protected. Attackers that can compromise passwords, keys,
session cookies, or other tokens can defeat authentication
restrictions and assume other users' identities.
4. Cross Site Scripting
– The web application can be used as a mechanism to
transport an attack to an end user's browser. A successful
attack can disclose the end user’s session token, attack the
local machine, or spoof content to fool the user.
August 1, 2006
OWASP Top 10 Vulnerabilities
5. Buffer Overflow
– Web application components in some languages that do not
properly validate input can be crashed and, in some cases,
used to take control of a process. These components can
include CGI, libraries, drivers, and web application server
components.
6. Injection Flaws
– Web applications pass parameters when they access
external systems or the local operating system. If an
attacker can embed malicious commands in these
parameters, the external system may execute those
commands on behalf of the web application.
August 1, 2006
OWASP Top 10 Vulnerabilities
7. Improper Error Handling
– Error conditions that occur during normal operation are not
handled properly. If an attacker can cause errors to occur
that the web application does not handle, they can gain
detailed system information, deny service, cause security
mechanisms to fail, or crash the server.
8. Insecure Storage
– Web applications frequently use cryptographic functions to
protect information and credentials. These functions and
the code to integrate them have proven difficult to code
properly, frequently resulting in weak protection.
August 1, 2006
OWASP Top 10 Vulnerabilities
9. Application Denial of Service
– Attackers can consume web application resources to a point
where other legitimate users can no longer access or use the
application. Attackers can also lock users out of their
accounts or even cause the entire application to fail.
10. Insecure Configuration Management
– Having a strong server configuration standard is critical to
a secure web application. These servers have many
configuration options that affect security and are not secure
out of the box.
August 1, 2006
August 1, 2006
SQL Injection
use DBI;
$dbh = DBI->connect($conn, $dbusername, $dbpassword) or
die “Database connection failed.\n”;
$sql = “SELECT count(*) from users where username =
‘$username’ and password = ‘$password’”;
$sth = $dbh->prepare($sql) or die “Prepare failed.\n”;
$sth->execute() or die “Execute failed.\n”;
What if user gives SQL code as name or password?
August 1, 2006
SQL Metacharacters
‘ quotes parameters
; separates commands
-- comments
%, _ glob in LIKE clause
%, _, *, +, |, [], () used for regular expressions in
SIMILAR TO clause
August 1, 2006
SQL Injection Attack #1
• Unauthorized Access Attempt:
– password = ’ or 1=1 --
• SQL statement becomes:
– select count(*) from users where username =
‘user’ and password = ‘’ or 1=1 -– Checks if password is empty OR 1=1, which is
always true, permitting access.
August 1, 2006
SQL Injection Attack #2
• Database Modification Attack:
– password = foo’; delete from table users where
username like ‘%
• Database executes two SQL statements:
– select count(*) from users where username =
‘user’ and password = ‘foo’
– delete from table users where username like ‘%’
August 1, 2006
Beyond the Database
• ODBC allows shell injection via “|”
– ‘|shell(“cmd /c echo “ & chr(124) & “format
c:”)|’
• MS SQL Server Extended Stored Procs
– Shell: exec master..xp_cmdshell ‘format c:’
– Create new DB accounts: xp_grantlogin
– Read any file: bulk insert foo from “c:\d.txt”
August 1, 2006
The Problem: String Building
Building a SQL command string with user
input in any language is dangerous.
–
–
–
–
Variable interpolation.
String concatentation with variables.
String format functions like sprintf().
String templating with variable replacement.
August 1, 2006
Bad Solution #1: Blacklist
Attempted solution: Blacklist SQL
metacharacters, especially single quotes.
Problems:
1.
2.
3.
4.
5.
6.
Numeric parameters don’t use quotes.
Database-escaped quotes: \’
URL escaped metacharacters.
Unicode encoded metacharacters.
Did you miss any metacharacters?
2nd Order SQL Injection.
August 1, 2006
Numeric Parameters
• Solution: Escape single quotes
• Problem #1: What if you use stored user data?
– Q: select count(*) from users where uid=$uid
– User enters uid = 1 or 1=1
– Query becomes:
• select count(*) from users where uid=1 or 1=1
• Once again, this query is always true.
August 1, 2006
2nd Order SQL Injection
• Solution: Escape single quotes
• Problem #2: What if you use stored user data?
–
–
–
–
User creates account with user = root’-Application escapes and inserts as root’’-User resets password.
Your query fetches username from DB to verify account
exists with correct old password.
– update users set password=‘pass’ where username =
‘root’--’
August 1, 2006
Bad Solution #2: Stored Procedures
SQL Stored Procedures build strings too:
CREATE PROCEDURE dbo.doQuery(@id nchar(128)
AS
DECLARE @query nchar(256)
SELECT @query = ‘SELECT cc FROM cust WHERE id=‘’’ + @id + ‘’’’
EXEC @query
RETURN
August 1, 2006
Solution: Prepared Queries
use DBI;
$dbh = DBI->connect(conn(), $db_username, $db_password) or
die “Database connection failed.\n”;
$sql = “SELECT count(*) from users where username = ? and password = ?”;
$sth = $dbh->prepare($sql) or die “Prepare failed.\n”;
$sth->bind_param(1, $username);
$sth->bind_param(2, $password);
$sth->execute() or die “Execute failed.\n”;
August 1, 2006
Additional Precautions
1.
2.
3.
4.
Don’t access the DB as a privileged user.
Don’t allow access to DB from Internet.
Don’t embed DB passwords in your code.
Don’t leak information in error messages.
August 1, 2006
Going Further
• Reading
– OWASP Top 10 Project
– OWASP Guide
– Hacking Web Applications Exposed, 2/e
• Software
– WebGoat (OWASP)
– Hacme Bank (Foundstone)
– MasterBugs
August 1, 2006
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Stephen J. Friedl, “SQL Injection Attacks by Example,”
http://www.unixwiz.net/techtips/sql-injection.html, 2005.
Gary McGraw, Software Security, Addison-Wesley, 2006.
Michael Howard, David LeBlanc, and John Viega, 19 Deadly Sins of Software Security,
McGraw-Hill Osborne, 2005.
Michael Howard, David LeBlanc, Writing Secure Code, 2nd edition, Microsoft Press, 2003.
Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press,
2006.
OWASP, The OWASP Top 10 Project,
http://www.owasp.org/index.php/OWASP_Top_Ten_Project, 2006.
OWASP, The OWASP Guide to Building Secure Web Applications,
http://www.owasp.org/index.php/OWASP_Guide_Project, 2006.
Joel Scambray, Mike Shema, and Caleb Sima, Hacking Web Applications Exposed, 2nd
edition, Addison-Wesley, 2006.
SK, “SQL Injection Walkthrough,”
http://www.securiteam.com/securityreviews/5DP0N1P76E.html, 2002.
John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002.
August 1, 2006