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.

Miss a column?

Check out the Security Solutions Archive,
and catch up on the most recent editions of Mike Mullins’ column.

Worried about security issues? Who isn’t? Automatically
sign up for our free Security Solutions newsletter, delivered each Friday,
and get hands-on advice for locking down your systems.

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.