'Slammer' Heightens Focus on Securing Web Apps

The outbreak in Asia of a rapidly spreading computer worm is the most aggressive assault on the Internet backbone since July 2001's "Code Red." The attack comes just as an international user group has issued its Top 10 Watchlist for how to keep web-based applications secure. Get the latest on the 'Slammer' and an in-depth summary on how to make sure your web apps are secure.

Tags: Server, Attack, Report, OWASP, Security, SQL Server, Web Applications,


The outbreak in Asia of a rapidly spreading computer worm is proving to be the most significant assault on the Internet backbone since July 2001's "Code Red." The current attack comes just as an international group has issued its Top 10 Watchlist for keeping web-based applications secure.

In this story, Integration Developer News provides the latest on the worm, code-named "Sapphire" or 'SQL Slammer.' IDN will also provide readers an in-depth summary from the web security report.

Inside the 'Slammer' Worm
Slammer slows down Internet access by attacking back-end servers -- primarily Microsoft's SQL Server 2000. According to Reuters' latest press reports, Slammer works by carrying a self-regenerating mechanism that enables it to multiply quickly across Internet servers, leaving client-side PCs unaffected. The press agency noted that Internet providers in South Korea appeared to be the attack's main targets, but added that, within hours, Slammer's replication capability had affected traffic flows in Japan and Eastern Europe.

At press time, Microsoft said its engineers and developers were working "around the clock" investigating the virus, which affects versions of SQL Server 2000 not currently up to date with the latest service pack (SQL Server Pack SP3).

The following is taken from Microsoft's official statement released on Saturday, Jan. 25:

"From our tests, it appears that SQL Server Service Packs SP1 and SP2 are vulnerable to this virus. Servers that are running the latest Service Pack 3 appear to be unaffected. We are continuing to test SQL SP3 to confirm that it is not vulnerable to this virus. At this time, we highly recommend that all of our customers running SQL Server 2000 update their servers immediately to SP3."

Readers can download the latest server pack (SP3) for SQL Server 2000 from the Microsoft website. Microsoft also said it would publish regular Slammer updates.

Apparently, many customers are taking the advice, as Microsoft added that "We are aware that many [SQL Server customers] are experiencing difficulties accessing the SP3 update. We are actively seeking a resolution to this issue, and will keep customers updated on our progress."

Report on Top 10 Web Apps Security Threats
Meanwhile, a coalition of enterprise computing leaders from the Open Source and enterprise IT communities, under the umbrella of OWASP (the Open Web Application Security Project), has released a valuable, thought-provoking report on how to identify -- and more importantly, try to prevent -- security threats against web-based applications, including XML, web services and web-to-legacy integration projects.

By releasing this report, OWASP said they want to increase awareness among developers of the types of vulnerabilities they may present to their web-based applications. (not simply static web pages). "The experts at OWASP have concluded these vulnerabilities represent a serious risk to [those] who have exposed their business logic to the Internet."

The topics in the report run the gamut of a broad range of security concerns, including access control, session management, cryptographics, directory services, guarding against insertion of invalid data, and even insecure server-to-server scripting. OWASP has done an admirable job in not simply identifying the threats, but also in helping developers and sysadmins identify ways the problems might be introduced into their systems, and techniques for shoring up their web applications' security.

This OWASP comment intrigued us at IDN by further suggesting that developers and sysadmins can get a lot of prevention from only a few ounces of cure, by taking a second look at some previously considered Best Practices.

According to the OWASP report, "These flaws are surprisingly common and can be exploited by unsophisticated attackers with easily available tools. When an organization deploys a web application, they invite the world to send HTTP requests. Attacks buried in these requests sail past firewalls, filters, platform hardening, SSL and IDS without notice because they are inside legal HTTP requests. Therefore, web application code is part of the security perimeter and cannot be ignored."

OWASP's Top 10 Web Apps Threats
Below, Integration Developer News has included an overview of OWASP's "Top 10" bogeymen for web services. The first five (5) examples, with permission, provide readers with a drill-down of some recommendations for coping with the problem. The entire 27-page report can be downloaded free from OWASP at . (Simply select a "mirror," and the report will be downloaded from that site. Approx. download time is less than 2 min.)

  1. Unavailable Parameters -- Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack back-end components through a web application.

    Any part of an HTTP request can be "tainted," the report said, recommending that "the best way to prevent parameter tampering is to ensure that all parameters are validated before use," using a component review process.

  2. Broken 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.

    The most important step is to document -- or whiteboard -- your web applications' access control and capture process. This documentation should include: types of users that can access an application; what functions and content each user types can access; retesting common threats including: insecure IDs, forced browsing; path transversal; file permissions; and client-side caching.

  3. Broken Account and Session Management -- Account credentials and session tokens are not properly protected. Attackers who can compromise passwords, keys, session cookies or other tokens can defeat authentication restrictions and assume others' identities.

    Strong authentication services and off-the-shelf session management tools can guard against many vulnerabilities that can arise from a broken session, but ensuring that technology is properly implemented is the key to its effectiveness, the report said. To that end, OWASP advised developers/sysadmins to pay special attention to several key areas, including: password change control, strength and storage; protecting credentials while "in transit" to avoid credential theft/hijacking; blocking access to account lists from browsers; and using POST (never GET) for submitting authentication and session data.

  4. Cross-Site (XSS) Scripting Flaws -- 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 to fool the user (or target server/destination).

    XSS attacks come in two flavors: "Stored attacks" permanently store injected code on target servers, databases, message forums and other areas. "Reflected attacks" inject code through secondary routes, such as e-mail, or through server-to-server communications. When a user (or a web service) uses a URL to check or submit data, the injected code travels to that target. The attack can also be "reflected" back to the originating user/service request because the target appeared to be a "trusted server," which can cause the originating browser/server to execute the tainted injected code.

    The best way to tell if your system or web applications are vulnerable, OWASP said, is to review your code and search for all places where input from an HTTP request could possibly make its way into HTML output. The report also notes for J2EE app server users that a variety of HTML tags can be used to transmit "malicious JavaScript." The report (on page 15) also suggests the most vulnerable HTML tags and suggest how they should be converted.

  5. Buffer Overflows -- Web application components in some languages that don't properly validate input can be crashed and, in some cases, even used to take control of a web-based process. These components can include CGI, libraries, drivers and web application server components.

  6. Command Injection Flaws -- Web application pass parameters when they access external systems or the local OS. If attackers can embed malicious commands in these parameters, the external system may execute those commands on behalf of a web application.

  7. Error-Handling Problems -- Error conditions that occur during normal operations are not handled properly. If attackers 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 Use of Cryptography -- 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.

  9. Remote Administration Flaws -- Many web applications allow administrators to access the site using a web interface. If these administrative functions are not carefully protected, an attacker can gain full access to all aspects of the site.

  10. Web and Application Server Misconfiguration -- 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 now secure out of the box.

OWASP is an Open Source community project staffed entirely by volunteers from across the world. The project is developing software tools and knowledge-based documentation that helps people secure web applications and web services. Much of the work is driven by discussions on the Web Application Security list at SecurityFocus.com.

Readers can learn more about OWASP membership and the group's agenda here.



back