Dr. Dobb's Journal - October 2008 - (Page 26)

D10fish_p3as 8/14/08 12:38 PM Page 26 Core Technology SAFE CODING PRACTICES used naively by the application at a later date to compromise the end user’s session. Query-based attacks focus on a prevalent antipattern that involves constructing queries on the fly using string concatenation. This vulnerability type shows up most frequently in web-facing applications, and is equally visible in all the usual page stacks— PHP, ASP, JSP, and so on—along with their backing controller logic. The core of this vulnerability revolves around developers using direct query execution rather than query preparation to run database interaction. Consider this example of a login validation query: SELECT ID FROM USERS WHERE NAME= 'user' AND PWD='password' stituted into a string form of the query by concatenation. Consider a set of parameters provided by an attacker: NAME: PWD: x x' OR '1' = '1 Run the concatenation and the result is the—now exploited—query: SELECT ID FROM USERS WHERE NAME= 'x' AND PWD='x' OR '1' = '1' Users are presented with a simple HTML form containing two input boxes and using this antipattern. The incoming parameters from this form (however they’re received by the page stack in question) are simply sub- Figure 1: Calling functions. If this is compounded by the login simply checking for success or failure of this statement’s execution (as opposed to counting result rows), attackers are quickly granted whatever access rights might be available from whatever user records are processed by the application. In applications where the first row of the user table is reserved for the superuser, the application could easily be completely compromised. There are many other forms of attack possible using applications that are not careful in their treatment of substitution strings within database statements. As common as this antipattern is (see recent announcements from Microsoft and others to see the prevalence that’s out there), the mitigation is very simple and is built into basic database APIs: Use prepared statements, not string concatenation. For example, consider the incorrect implementation in Example 2. This function follows the antipattern rigorously, and also performs another significant no-no by throwing an exception that includes incoming (unfiltered) data—the user name. Put this data up in front of the user as a response and you’re open to several knock-on exploits, notably the potential for cross-site scripting. To fix this code, instead of constructing the SQL query on the fly, simply construct a prepared statement and then use it to substitute the incoming parameters. The statement that we’re going to prepare reserves space for parameters and is not vulnerable to this exploit because it isn’t lexically brittle in the same way as string concatenation. Consider this statement (which I’ll prepare for the same purpose as the aforementioned concatenated string): SELECT ID FROM USERS WHERE USER=? AND PWD=? public void validateUser(String user, String pwd, Connection db) throws InvalidUserException { Statement stmt = null; ResultSet rs = null; try { // Create the statement stmt = db.createStatement(); String sql = "select id from users where user='" + user + "' and pwd=’” + pwd + "'"; // Execute it, process the result rs = stmt.executeQuery(sql); if( rs == null || rs.next() == null ) throw new InvalidUserException(user); } catch( SQLException e ) { throw new InvalidUserException(user); } finally { try { if( rs != null ) rs.close(); } catch( Exception e ) { } try { if( stmt != null ) stmt.close(); } catch( Exception e ) { } } } I use this prepared statement to substitute our incoming data into the user and pwd parameter reservations. If we provide the same previously exploited strings as input, the result will be a failure during query substitution, as you can’t provide an argument to a prepared query that includes metacharacters like the single quote. Other potential exploits will be caught at different stages, but as you can see the new implementation, as in Example 3, is just as simple to create as the original, but is now much safer (we’ve also removed the username from the thrown exception, to avoid any temptation to expose it unfiltered to the caller). In general, whether working with queries or DML, when dealing with data coming from the end user, always use prepared statements to take advantage of filtering and parsing built into the database itself. Cross-Site Scripting (XSS) One of the first restrictions placed on JavaScript in early browser versions was to build a wall around page content so that scripts executing within a frame served by one site could not access content of frames served by another site. Cross-site scripting, Example 2: An incorrect implementation. 26 Dr. Dobb’s Journal l www.ddj.com l October 2008 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - October 2008

Dr. Dobb's Journal - October 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer’s Notebook Is Your Next Language COBOL? Conversations Safe Coding Practices Code Signing in Adobe AIR OpenID Single Sign-On The Book Cipher Algorithm Indexing and Searching Image files Extending Continuous Integration Into ALM The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - October 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.