MSDN Magazine - November 2008 - (Page 48)

Reviewing code is a slow, tedious, and mind-numbing task. ry string, the application will choose the malicious script input for the value of the lastLogin variable. If you answered XSS, give yourself one point. HttpContext.Application object is not shared across servers. If this application was deployed in a server farm, it could lead to session ID collisions. If you caught this bug, give yourself one point. Another serious problem is that the session IDs generated by this class are easily guessed sequential integers. If a user looks at his session token and notices that he has session ID 100, he could use a simple browser utility to change the session ID to 99 or 98 or any other lower value to hijack those users’ sessions. A much better option for the developer in this case would be to use a GUID or other large, random, string-combining letters and numbers. If you realized that sequential integers are poor choices for session ID tokens, you score a point. Bug #7 (C#) private decimal? lookupPrice(XmlDocument doc) { XmlNode node = doc.SelectSingleNode( @"//products/product[id/text()='" + Request["itemId"] + "']/price"); if (node == null) return null; else return (Convert.ToDecimal(node.InnerText)); } Answer If you said XPath injection, give yourself one point. XPath injection works on exactly the same principle as its much more (in)famous cousin SQL injection. By creating a query that combines XPath code with unvalidated and unescaped user input, this code is vulnerable to injection attacks. Any application that manipulates text that is then used to perform some form of operation is subject to injection vulnerabilities. Bug #9 (C#) bool login(string username, string password, SqlConnection connection, out string errorMessage) { SqlCommand selectUserAndPassword = new SqlCommand( "SELECT Password FROM UserAccount WHERE Username = @username", connection); selectUserAndPassword.Parameters.Add( new SqlParameter("@username", username)); string validPassword = (string)selectUserAndPassword.ExecuteScalar(); if (validPassword == null) { // the user doesn't exist in the database errorMessage = "Invalid user name"; return false; } else if (validPassword != password) { // the given password doesn't match errorMessage = "Incorrect password"; return false; } else { // success errorMessage = String.Empty; return true; } } Bug #8 (C#) public class CustomSessionIDManager : System.Web.Session State.SessionIDManager { private static object lockObject = new object(); public override string CreateSessionID(HttpContext context) { lock (lockObject) { Int32? lastSessionId = (int?)context.Application ["LastSessionId"]; if (lastSessionId == null) lastSessionId = 1; else lastSessionId++; context.Application["LastSessionId"] = lastSessionId; return lastSessionId.ToString(); } } } Answer Answer There are two main problems here. While the code cor- rectly applies a lock around the app logic to ensure that two threads don’t create the same session ID at the same time, it’s still not safe to deploy in a server farm. Application state as referenced by the Learn to review code for security bugs. It’s a dying skill. 48 msdn magazine The biggest problem here is that the application is returning too much information to the user in the case of a failed login. While it’s definitely helpful for a user to know whether he just mistyped his password or whether he completely forgot his user name, this information is also useful to an attacker attempting a brute force attack against the application. Although it sounds counterintuitive, in this situation it’s better to be unhelpful. Failed logins should display messages such as “Invalid username or password,” not “Invalid username” and “Invalid password.” If you caught this, you get a point. And give yourself a bonus point if you also remembered that the application shouldn’t be storing passwords in plaintext in the database; instead, it should be storing and comparing salted hashes of the passwords. Security Quiz

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 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.