Tech

Guides

Business Applications ▪ Database Management ▪ Disaster Recovery ▪ Enterprise Servers & Storage ▪ IT Security ▪ Java ▪ Microsoft Office Suite ▪ Network Admin ▪ Open Source ▪ SMB ▪ SOA ▪ Tech Management ▪ Software/Web Development ▪ Windows Server ▪ Wireless Tech

IT Security TechGuides

Keep your Web applications secure

By Michael Mullins, TechRepublic
Tuesday, May 23, 2006 02:55 PM

When it comes to Web application security, many companies just scan their systems for vulnerabilities and call it a day. But that's a mistake.

Web-based applications are the portal of choice for mischief and illegal entrance to your organization's network. That's why you need to defend your network by arming yourself with the knowledge of how attacks occur--and learn how to fix the problem before someone finds holes in your network security armor.

When it comes to Web application security, many companies just scan their systems for vulnerabilities and call it a day. But that's a mistake: Don't rely on system security analysis of the Web platform to indicate whether the application is secure. These are two entirely different areas, and you should address them separately for any network application.

Let's take a look at the top three Web application security flaws you need to be on the lookout for.

Authentication
Authentication is the most critical phase of Web application security--even when you're using SSL and strong two-part authentication (i.e., userid and a complex password). Defective credential management tasks, including password change, user information update, and other related functions, can weaken authentication. That's why all account management tasks should require reauthentication even if the user has a valid session token.

For most Web applications, user authentication involves a userid and password. Stronger methods of authentication are widely available; options include both software- and hardware-based cryptographic tokens as well as biometrics.

While these methods add cost to your application, you should insist on their inclusion in the development process. If you're having trouble convincing the powers-that-be, consider this: The Federal Deposit Insurance Corporation (FDIC) concluded almost a year ago that, due to the growing problem of identity theft, online banking had the obligation to initiate multifactor authentication (e.g., software/hardware cryptographic tokens and biometrics) to supplement traditional two-part authentication.

Access control
Access control is how Web applications use authentication to grant or deny access to content and functions. Let's take a look at two main access control issues.

Path traversal: Malicious users perpetrate this attack by providing relative path information (e.g., https://your_website.com/target_dir/target_file) as a direct request for material. These attacks attempt to access files that normally aren't directly accessible. URLs with a Web browser, system calls, and shell commands using a hacking utility help facilitate such attacks.
Client-side caching: By default, most Web browsers cache Web pages. Attackers can access that information to gain access to a secure site. Users frequently use public or shared computers to access information via a Web application. That's why Web applications should include methods of restricting the caching of sensitive information to prevent the caching of user information in the browser.

Unvalidated input
Web applications respond to user HTTP requests, and attackers alter HTTP requests (e.g., URLs, query strings for backend databases, form fields, and hidden fields) to attempt to bypass the site's security mechanisms. The most common attacks result in cross-site scripting, buffer overflows, and SQL injection.

Web sites that rely solely on client-side mechanisms to validate input care only about site performance and usability. Attackers can easily bypass this checking mechanism, leaving a Web application without adequate protection against malicious input.

Hackers generate their own HTTP requests using tools intended to bypass the validation built into Web browsers. Server-side checks are necessary to defend against these forms of HTTP request exploitation attacks.

Where does this lead?
If Web applications are so inherently insecure and contain so many dangers, how do you implement security? The answer is relatively simple.

During the application build process, code documentation and independent code review are the key to your security success. Document every line of code, and get a third party that specializes in application security to evaluate the system and the control methods used to update the application.

If your Web application is already online and you missed that phase of security, it's not too late--you can still secure your application. Even if you conducted an extensive code review before deployment, you must continue to test and maintain that application for security leaks and vulnerabilities.

When it comes to Web application security testing, you have several excellent choices. If you're unsure where to look, a search of mySimon for web application security tool will offer a good starting point.

Final thoughts
If you deploy an application, people—both internal and external to your company--will test that application. Continue to conduct application vulnerability and penetration testing before all application deployments, as well as after each major application change.

System security checks will only offer information on the platform--not the application. Take the extra step, and secure the application.

Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.