Home > Security Programming > Top Ten Most Critical Web Application Security Vulnerabilities

Top Ten Most Critical Web Application Security Vulnerabilities

March 22nd, 2010

Web application security is often viewed incorrectly as a set of server and host-based security issues, rather than code-level and configuration-based security vulnerabilities. Although servers and hosts may still be the cause for exploitations, it is critical that security professionals recognize the major impact of poorly written web applications as well as how their applications and servers are configured separately and in combination. The Internet is increasingly responsible for handling and storing information and files of a sensitive nature requiring security and protection. Keeping hackers at bay and assuring the privacy of private and proprietary documents is paramount. Below are the top ten security vulnerabilities and how Security Programmers mediate these to prevent exploitation.

Security Web Programmers are often not given the clout nor the attention they deserve. Security programmers apply a much higher degree of attention, detail, and time to programming. Secure software may require more time and money than insecure software. A comparison must be made between the cost of securing web applications, and an insecure web application bringing the business down or releasing sensitive information to potentially nefarious hackers.

Don’t be misled by security misnomers or be mistaken about your security requirements. Security factors can be well-defined and explained at any level of your corporate structure. Emagined Security employs security programmers who are trained and experienced to develop secure software, including web and database applications. Our proven security programming techniques and multi-layered security development protocols ensure your web applications are protected and your sensitive information secured.

Issue 1: Lack of Data Validation & Data Cleansing
Information sent to your server from web requests that is not validated and cleansed before being handled by a web application produces an environment for attacks. The vast majority of compromised servers are broken as a result of this security vulnerability. A common security misnomer is that, “my firewall will protect my server.” Firewalls may limit the traffic that reaches your web applications, but a poorly developed web application creates vulnerabilities to traffic that firewalls do not filter or prevent.

Resolution 1: Wherever a user may submit information to your server, there is a requirement for data validation and data cleansing. From a programming point of view, any information that reaches a web application can be inspected for filtration, rejection, or approval prior to being handled by the expected web application modules. Whereas a firewall does not filter traffic, an IDS (Intrusion Detection System) can inspect traffic for predefined attack patterns prior to reaching the web application, and is advised. A common security misnomer is that SSL (Secure Socket Layers) will protect your customers, yet can create another layer of security vulnerabilities, if traffic is decrypted after passing through the IDS rather than before. IDS does not decrypt traffic, so SSL-encrypted traffic must be decrypted prior to the IDS, allowing IDS to inspect “plain traffic data” for attack patterns.

At the programming level, web applications should inspect all incoming data for attacks and abuse to create a layer of web application security. Bear in mind that some scripts may accept traffic from sources other than the expected web forms and points of origin. A hacker may submit a form via a POST request directly to the server without ever visiting the web site or using a web form. Data types can be modified easily and re–submitted multiple times in an attack. The web application should be designed to handle a specific data set of expected data types, not to accept any or all submitted data. Every Value sent to the server has a Variable that can be addressed individually for the expected format, pattern, content, and illegal characters.

A simplified example of data submission and data validation and data cleansing would be the simple newsletter signup form. The user is expected to submit an email address, which the server would place into a database for storage and perhaps send an alert email to the newsletter manager. Three critical points of programming come into play here. The email address is handled by code, the database is updated with the supplied email address, and an email is sent using the email address. The vulnerability arises when the insecure programmer assumes a nice shiny belief that the only data submitted will be an email address. The exploitation arises when the hacker submits something ther than an email address, such as a String of Code, an SQL Injection, or another attack. Without programming-level measures in place, the web applicati0n may be compromised, not to mention the server, the database, and sensitive information as well.

Data Validation is a security programming technique that inspects the submitted “email address” to determine if the pattern matches that of a real email address format. If the data does not meet the requirements for being an email address, the data is dropped and the user messaged to say that the web application is not vulnerable, hopefully diminishing ongoing attacks. Data sent as an attack should certainly not be sent to the database, but it can be modified for administrator review and inserted into security logs or emailed inside an alert. Data Cleansing is the process of removing illegal characters or patterns, and rendering attack strings inert so they may be handled by the web application.

Beware the common mistakes of assuming a radio button or checkbox will not create a point of data tampering. Attackers can send anything they want to a web application using the variable names of anything they define, including radio buttons, checkboxes, and file upload fields using standard POST/GET requests and using AJAX connection methods. AJAX (and Javascript in general) have created a large resource of attack points for exploitation since a larger assumption is made by insecure programmers that the AJAX connections will not become points of attack, for the same reasons they assume for form objects.

Issue 2: Broken or Lacking Access Controls
Member-Restricted and Administrator-Restricted access is often granted to provide control over websites, databases, and various information types. When there is a lack of control over who accesses data and which restrictions really apply, attackers may access accounts, sensitive information, and levels of administration that they should not. A member who gains access to administration functions that delete members or downloads a copy of the database is not a good thing, and can destroy member and investor loyalty. This vulnerability will not meet HIPPA Compliance, PCI Compliance, and other compliance mandates in different industries such as the medical and financial sectors.

Issue 3: Broken or Lacking Authentication and Session Management
Restricting access to a web application, and the data it is supposed to protect, requires protecting the access credentials and authentication schemes. A common attack to gain access rights of other users is called Sessi0n Hijacking. Sessions are closely associated with Cookies, and together these storeUser Names, Passwords, Access Keys, and other vital information used to allow or deny access to sensitive information. Cookies are stored in user browsers where sessions are stored on the hosting server.

Secure techniques allow the storage of sensitive authentication tokens in the session only, not the cookie, and use the cookie only to store the Session ID that connect the cookie (browser) to the correct server-side session. Secure server configurations are required to assure randomized session ID values that are not easily predicted and to assure storage of sessions is secure. Sessions must track a fingerprint of the user, including the IP Address, browser type and language, platform, and other trackable data types for fingerprinting. Tracking the time the session started and restricting its duration of use is another useful security technique. The concern is that a hacker may copy the session ID from the transmission between the user and the server, then integrate that session into the traffic on another machine and access the user’s account and web application functions.

Resolution 2 & 3: Securing sessions may impede Session Hijacking, but there is another layer of programming required for authentication schemes to operate securely. Data Validation and Data Cleansing (ab0ve) must be employed in all transactions. Enforcement of unique user names must be employed to prevent users with the same User Name from accessing incorrect accounts. A well-defined access control list should determine what the user may access, not a list of what the user may “not” access. Authentication and access control modules should be integrated into a single modules or system and applied globally, allowing global updates and corrections. SSL encryption should be used to help prevent attackers from listening to the traffic for sensitive information, and SSL Enforcement is advised. Unathorized access attempts should be logged and alerts sent for review and potential remediation.

When new modules are added for user access, a complete security review must be performed to assure vulnerabilities have not been introduced. When systems that require authentication are hostedd on the same server ass systems not requiring authentication, the security programmers should review the insecure programming modules for vulnerabilities to their systems, else host the authentication-restricted media on a separate server. Security vulnerability assessments should be scheduled and performed as a routine security measure. Although there are other techniques and aspects to securing authentication systems, these measures are a good basic review.

Issue 4: Cross-Site Scripting (XSS) Vulnerabilities
Cross-Site Scripting is an attack method that introduces remote web components into the host site, or transports the site user to a remote web site. The goal of the attacker is to make the user execute remote code or modules that reveal user authentication, sensitive information, or create access to the host site in some form.  Methods of attack include inserting XSS code into the host database, using methods such as Code Injection or SQL Injection. The attacker may modify the web file code on the host server to include Active-X controls, redirection methods, iFramed content, or other attack types. The results of these XSS attacks range from revealing authentication credentials to feeding sensitive information to a remote user or host, proprgating the attack to other members or administrators of the site, and creating Man-in-the-Middle attacks such as Phishing attacks. Some attacks may become visible immediately with or without repercussions, while other may reside actively or latent on the host server feeding data to remote hackers regularly or waiting for a trigger to launch a more complex or timed attack.

Resolution 4: XSS Cross Site Scripting requires due diligence of a security programmer and includes other resolution description above and below. The vast majority of web application exploitations result from poor programming. Server configurations such as Magic Quotes and Strip Tags may reduce the chance of injections from being successful. Correctly placed and configured IDS with updated match patterns helps reduce the chance of attack traffic from reaching the web application. Most importantly, Data Validation and Data Cleansing must be included at every level of security programming to protect the web application from many various attacks.

Issue 5: Buffer Overflow Vulnerabilities
Some web application components in some languages do not correctly validate user-submitted input and may crash or freeze a server. IN some situations a Buffer Overflow may used to take control of a process, despite being difficult to execute. Vulnerable components can include CGs, DLLLibraries, Various Drivers, and some web application server components. This attack is performed by submitting more information than a variable is expecteing to receive, causing the “overflow” of data to write over a section of memory where another process may subsequently access and execute it. If the section of overwritten code contains the correct executable content for the process that happens to access it, the results could range from a defunct server or process to a compromised server with associated exploitations.

Resolution 5: In most cases, buffer overflows are not the responsibility of the security programmer as much as that of the server administrator. The physical server itself must be correctly configured and updated with the latest security features and patches. Vulnerabilities in languages asuch as ASP, PHP, CFM and others must be addressed by the developers or communities and the updates and upgrades applied quickly. Hackers are just as well-informed about buffer overflow problems in software as the security professionals, since buffer overflow problems are almost always public information.

If the hacker knows what version of server software you utilize, and a security vulnerability is announced for your version, that hacker may immediately attack your server with a well-defined attack point. For this reason, your server should never announce which type or version of software is running. In fact, the option exists to mislead the attacker by declaring a different server software name or version.

Buffer overflows are not easy to execute successfully and usually require multiple attack attempts. Keeping your server up to date for all software packages is required, and using an updated and correctly placed IDS is important. There is not much a security programmer can do to mediate buffer overflow attacks, but data validation may reveal attacks of this nature and alerts may be used to bring attention to logs and advise admins to look for attacks and their sources.

Issue 6: Code Injection & SQL Injection Vulnerabilities
This is my favorite aspect of hacking, since it is very much a programming-level attack technique. Referring to the email address and newsletter signup example above, an incorrectly programmed handler of submitted data may allow unexpected data to exploit the web application or server. An SQL Injection is a type of Code Injection. A Code Injection sends programmer’s code to the server inside a variable. If the web application (or IDS) does not identify the variable’s contents as invalid, the code that is sent may be executed by the web application. An SQL Injection is a specific type of Code Injection in which the web application’s database is the target of the attack.

Code Injections may come in many flavors that include anything your programming language can perform, given permissions restrictions on the server. In the newsletter signup example, the expected value is a regular email address. However, if that variable contains a section of code that is correctly written to insert itself into the server-side web application code, the server may execute the targeted script including the attacker’s code. Given the range of possibilities defined by the language itself, the worst case scenario is that the code creates a situation allowing the upload of a root kit to the server and the whole server is owned by the attacker.

SQL Injections are the same as a Code Injection except that the target of the attack is the database. Using Sequel Querying Language (SQL), the injected code may connect to the database to delete all contents, feed the entire database to the remote hacker, insert whatever records the hacker defines, or modify existing records. Using an eCommerce system as another example, an attacker may wish to retrieve credit card profiles or create records causing the business to deliver products or services without being paid.

Resolution 6: Employing Data Validation and Data Cleansing techniques from above, SQL Injections may be easily mediated.  Techniques include individual value inspection, configuring the web application to use Magic Quotes, and configuring the web server language and database to handle cases of string escaping.  Deprecated methods such as using “mysql_escape_string()” must be remediated with modern code or higher value techniques. Data Cleansing and Validation is the bottom line for preventing Code and SQL Injection attacks. Where SQL Injection attacks may be difficult to identify without IDS or advanced SQL Injection prevention programming techniques, slash notation handling may be required.

Given a website that stores samples of SQL Queries and commands for SQL researchers, a text field may contains SQL string that will be tough to differentiate from SQL Injection attempts. Although this is an uncommon situation, it illustrates the fact that there are times you simply accept the data and “add slashes” to the data so it is not executed by the server or database. Magic Quotes is another example of server language and programming-level technique for mediating SQL or Code Injections.

Issue 7: Poor or Lacking Error Handling
Errors can be created on almost every web application, but the difference between a crafted web application and a poor web application is how the error is handled. A server that is configured to operate in Debug mode may offer considerable information about the error, which may reveal server and application pathways, file names, code segments, server types and versions, and other information. All of these contribute the to resources the attacker will use to exploit the web application and server. Once a poorly handled error is discovered, an attacker may iterate man types of errors to collect a wide range of information about the server.

Some errors, especially crafted errors by an attacker, may result in denial of service or cause the server to fail in some form. Some security features of the web application may become voided by some error situations, creating yet more vulnerabilities. The nature of the potential vulnerabilty depends on the nature of the mishandled error and the server or web application environment.

Resolution 7: All errors must be handled either with specific error handlers for expected errors, or with broad error handling mechanisms for unexpected errors. The server should not operate in debug mode once launched into production, and development systems must be kept inside intranets (or securely on the Internet) where they may operate safely in debug mode. At the server level, all errors may be written to error logs regardless of being in production mode instead of debug mode. The amoutn  of logging is independent of the operation mode, so logging may remain in debug mode while the server is not in debug mode. The pages that result from errors should specifically or generally return a designed web page containing navigation back into the site, no debugging content for general users, and not reveal the facts related to a true error. General users will return to the site unaware that there was an error, while attackers may be misinformed to think their attacks did not succeed.

Issue 8: Insecure & Improper Data & File Storage
All too often poorly programmed websites provide easy access to credit card profiles, restricted areas of the web application, and to sensitive documents and information. Information and file management is a growing concern and must be addressed. Information stored in databases may not be protected by authentication or encryption. Sensitive files stored on the server may be directly browsed simply by side-stepping authentication. Authentication techniques may be incorrectly applied or insufficient to protect data and files.

Resolution 8: Correctly securing data and files requires two different approaches to the same results. Data stored in the database requires different security techniques from files stored on the server, yet there are some techniques that are the same. The type of data stored inside the database record or file may affect the technique for securing the content.

Protecting simple passwords may be as simple as using one-way or two-way encryption, depending on the type of server the web application is hosted on. One-way encryption means the user’s password is encrypted using the same one-way encryption then compared against the encrypted password in the database. Failure requires the password be changed via some other mechanism, which can create vulnerabilities in itself. Two-way encryption may be the decryption of the password stored in the database and comparison against the submitted password. If the server is a shared hosting server, one-way encryption is necessary, yet may become a moot point when misconfigured web hosts allow neighboring web applications access to browse the web files that contain the encryption/decryption code.

File storage is a somewhat different issue since the information is stored as flat files on the file system. If possible, store the files outside of the web root, where permissions are more restricted. Do not store files with the original file name of file URI. Track the files and use a file name that is a tracking ID without a file extension. Stream the file contents to the user and name the file on-the-fly.

Issue 9: Denial of Service Vulnerability
A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer resource unavailable to its intended users. Although the means to perform a DoS attack may vary, it generally consists of concerted efforts to prevent an Internet site or service from functioning efficiently or at all. DoS attackers typically target sites or services hosted on high-profile web servers such as banks, credit card payment gateways, and even root nameservers. The term is generally used with regards to computer networks, but is not limited to this field, for example, it is also used in reference to CPU resource management.

One common method of attack involves saturating the target (victim) machine with external communications requests, such that it cannot respond to legitimate traffic, or responds so slowly as to be rendered effectively unavailable. In general terms, DoS attacks are implemented by either forcing the targeted computer(s) to reset, or consuming its resources so that it can no longer provide its intended service or obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately.

Resolution 9: Preventing Dos and DDoS attacks requires the integration of multiple prevention techniques. Firewalls can limit the traffic to the server. Switches and Routers that can handle high volume traffic are often able to detect and limit throughput based on too much traffic or a detected DoS attack. Front-end application hardware in conjunction with switches and routers may identify and handle traffic ans normal, priority or potentially dangerous. IP Based restrictions may help throttle traffic and limit or mediate DoS attacks. Blackholing (sinkholing) may be used to redirect DoS traffic to dead-end IPs and destinations. Low-volume web environments may make more use of programming-level prevention, but DoS/DDoS prevention is more of a server and network level remediation approach.

Issue 10: Lacking or Poor Configuration Management
A poorly or incorrectly configured server and server modules will potentially create multiple security vulnerabilities. Network configuration is also important for securing the server and its environment. A secure web application requires a strong server configuration. Many servers and software packages are distributed with an insecure configuration out of the box. A default server may have many features turned on for convenience, including Open STMP Relay,  Anonymous FTP access, and other insecure features which may be desired after being reconfigured. Some defauly systems may have software packages that are pre-installed and should be removed. Operating a server with a default software setup and configuration may cause multiple security vulnerabilities that may be exploited by hackers.

Resolution 10: Server configuration is not typically the responsibility of the programmers, and should be addressed by server and network administrators. The host server should be assessed for security issues, which will usually reveal what packages are installed and their versions, missing patches and updates or upgrades, and provide a hit list for which packages should be removed, disabled or correctly configured. Before putting the server into production, a security vulnerability scan should be performed, followed by a code review of the web application.

Emagined Security
If you have questions about Secure Web Programming, or have concerns about your current web applications, you may contact me at andrewlandsman at emagined dot com or call Emagined™ at 888.235.1906 for a Security Consultation.

Categories: Security Programming Tags:
Comments are closed.