August 1, 2006

The Software Security Problem

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

August 1, 2006 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 InputUnvalidated 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 ControlBroken 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 ManagementBroken 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 ScriptingCross 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 OverflowBuffer 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 FlawsInjection 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 HandlingImproper 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 StorageInsecure 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 ServiceApplication 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 ManagementInsecure 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

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.Numeric parameters don’t use quotes. 2.Database-escaped quotes: \’ 3.URL escaped metacharacters. 4.Unicode encoded metacharacters. 5.Did you miss any metacharacters? 6.2 nd 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, nd 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 nchar(128) AS nchar(256) = ‘SELECT cc FROM cust WHERE id=‘’’ + ‘’’’ 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.Don’t access the DB as a privileged user. 2.Don’t allow access to DB from Internet. 3.Don’t embed DB passwords in your code. 4.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.Stephen J. Friedl, “SQL Injection Attacks by Example,” Gary McGraw, Software Security, Addison-Wesley, Michael Howard, David LeBlanc, and John Viega, 19 Deadly Sins of Software Security, McGraw-Hill Osborne, Michael Howard, David LeBlanc, Writing Secure Code, 2 nd edition, Microsoft Press, Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press, OWASP, The OWASP Top 10 Project, OWASP, The OWASP Guide to Building Secure Web Applications, Joel Scambray, Mike Shema, and Caleb Sima, Hacking Web Applications Exposed, 2 nd edition, Addison-Wesley, SK, “SQL Injection Walkthrough,” John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002.