WEB APPLICATIONS ARE AN ESSENTIAL PART of the online experience. Every day, companies roll out Web applications to increase the appeal, functionality, and interactivity of their Web sites. These applications can take the form of portals, shopping carts, Web mail, online auctions, forms, discussion groups, and more. For all the good these Web applications introduce, they also bring a host of new vulnerabilities and security threats. Malicious users may invade a Web site through "backdoor access" of an unsecured Web application, completely circumventing perimeter security measures.
This chapter details the causes of these vulnerabilities and the largest targets for Web applications. In addition, this chapter contains information on secure coding best practices to help mitigate these risks from the beginning. To help understand changes that are made to any Web application source code, software development configuration management is essential; it tracks and controls any changes made. Revision-level tracking identifies what information was changed during any update, as well as when and by whom. The final section outlines how to mitigate Web application vulnerabilities and what the best practices are. It is important to keep these aspects in mind when designing any Web application because security of user data is essential to online components.
The extensive use of the Internet for e-commerce enables companies to interact with customers from all over the world. Although the Internet allows a company to be available on the global market 24/7, Web applications on these sites can create security vulnerabilities that allow a malicious user to gain access to sensitive information, interrupt business activity, and commit fraud.
To better understand where vulnerabilities occur, it is important to understand what a Web application is. A Web application is a software program that generally contains computer scripts that interact with the end user. Some examples include Web mail, shopping carts, portals, games, forums, forms, online auctions, and other interactive Web page elements. A Web application consists of three main components: the Web server responsible for sending requested pages to the end user's browser, the application server responsible for processing data for the end user, and the database that stores all the required data.
With the growth of Web 2.0, Web applications are a common feature of Web site designs. The largest benefit of a Web application is that it enables thousands of users to interact with the site simultaneously. However, the benefit of incorporating Web applications to a Web site comes with a price. If applications are not coded and maintained correctly, they can open an unwanted doorway to an internal network. Therefore, before integrating a Web application, the designer must be aware of the associated risks as well as measures to mitigate those risks.
Over time, network administrators have established strong methods of securing the network perimeter. Firewalls, demilitarized zones (DMZs), intrusion detection systems (IDSs), secure protocols, and more have been combined to create strong perimeter security. To some extent, the security battle has shifted from almost a sole focus on perimeter security to internal security. That's because hackers look for different methods to gain access to sensitive information and attain their goals. It is estimated that about 70 percent of all hacking attempts against an organization's Web site come from the application layer. This indicates that hackers see Web applications as a prime target and that it is possible to take advantage of weak structure and coding to gain access to an organization's servers. Hackers often study the source code of a Web site to better understand its structure, and then target areas that appear weak. Three main areas targeted are:
A common security weakness of many Web applications is the failure to provide a strong authentication system to determine who the end user is. It is important to create a process in which end users must identify themselves with the appropriate credentials to gain access to the Web application. Without this precaution, a malicious user can gain access to another user's account, view sensitive information, and perform unauthorized tasks. The top concerns regarding authentication break down into four target areas:
Elevation of privilege—When designing an authentication process, you must keep in mind that a hacker can try to gain access to an administrator's or local user's account and increase his or her privileges. In this process, a hacker overtakes all system processes and controls the Web application. Certain types of classic programming allow commands to run the application as the account with the highest amount of privilege, such as an administrator on the local machine. This grants the hacker all access to your Web application, data, and task management.
Disclosure of confidential data—Confidential data disclosure occurs when users who are not authorized to view sensitive information gain access to it. Any data can be classified as confidential. In particular, customer credit card numbers, employee information, and financial records are at greatest risk when dealing with an insecure Web application. Restricting access by creating a strong authorization process is vital to ensuring all sensitive information is kept confidential and not accessed by a malicious user.
Data tampering—Tampering with data is the process of an unauthorized modification to any information on a system. With a weak authorization process, any user can alter company or customer data, delete files, and alter the structure of a system. Authentication must be in place to mitigate the risk of data being tampered with.
Luring attacks—In the method of luring, the malicious user tries to gain access by using an account with few privileges to coerce an entity with more privileges to perform an action on behalf of the malicious user. It is important to know who is logged on to the Web application to deter these attacks upon authorized users.
A hacker will attempt to compromise your Web application by analyzing every aspect of its design. One area of close examination is what type of input validation your Web application runs, if any. As previously mentioned in this book, invalidated or poorly validated user input is a major threat to Web sites, databases, and Web applications. If malicious users discover that your Web application makes assumptions about the type, length, format, or range of input data, they will manipulate this weakness to achieve their own goals. When a secure Web application is designed, the only aspect that can be manipulated is public access areas. If your Web application is designed to blindly trust input, your application is weakened and at risk for the following:
Buffer overflows—A buffer overflow is defined as a process in which data is stored in a buffer outside the designated memory that the programmer has set for the application. The extra data then overwrites the adjacent memory, which may contain program flow control data. The result: typically erratic program behavior, crashes, and program termination. If a buffer overflow occurs, the application is more susceptible to denial of service (DoS) attacks or code injection. If a DoS attack occurs within a Web application, the processes performed by the targeted application will crash. If a hacker injects code into the script of the Web application, the code alters the way the program executes and causes it to run the attacker's injected code instead.
Cross-site scripting (XSS)—As discussed in Chapters 6 and 7, cross-site scripting is defined as a computer security vulnerability that typically occurs in Web applications. This particular vulnerability allows a malicious user to inject client-side scripting into Web pages that are viewed by others. When attackers exploit cross-site scripting, they use it to bypass access controls of the Web application. In an XSS attack, a code created by the hacker runs in the user's Web browser while the browser is connected to your Web application. Essentially, a cross-site scripting attack uses your Web application as the vehicle to attack your end user, not the Web application itself.
To initiate the cross-site scripting attack, the hacker presents a link that persuades the user to click on it and launch the vulnerable page within your Web application. The links typically arrive in e-mails, newsgroup postings, or by using the name of a trusted company or site that actually points to the vulnerable page. When the user activates the link, unvalidated code is sent to the Web application. In the event the Web application takes the query strings, fails to authenticate, and returns the code to the browser, the script is then executed. Typically a pop-up message is displayed, which allows the hacker to extract the user's authentication information. This allows hackers to gain authenticated user information, so they can log onto the Web application and gain privilege.
SQL injection—An SQL injection is caused by exploiting the database layer of a Web application. A hacker using this technique can inject code and compromise the security of your Web application. The vulnerability is noticed when user input is incorrectly filtered in SQL statements, or when user input is not strongly limited or filtered and can be unexpectedly executed. SQL injection can occur when your Web application uses input to construct SQL statements to access the database layer. Another area where SQL injection may occur is if your Web application uses stored procedures that contain unfiltered user input. By taking advantage of this method of attack, the hacker can run commands arbitrarily in the database. This becomes a larger issue if the application uses an over-privileged account to connect to the database, further compromising any other connected system.
Sessions allow a user to access a network or Web-based resource repeatedly, without having to reauthenticate every time. That is, once users have been authenticated and verified through an authentication method such as a username and password, they will not need to reauthenticate until they logoff and end the session. Each authenticated user is assigned a session ID (SID). If a malicious user can gain the session ID, obtaining the authentication credentials is not necessary and the malicious user has access to the session. The session may be a network communication, online financial transaction, day trading, and more.
Session management is the term used to define how systems handle and manage user sessions. Session management security lies within the application layer of the database. To maintain an overall secure environment, it is critical to have session security. Top security threats to session management are:
Session hijacking—Refers to the exploitation of a valid computer session to gain unauthorized access to information and services within a targeted computer system. Within a Web application, a session can be hijacked when the hacker uses network monitoring software to steal the authentication tokens (cookies) that are used to represent the authenticated user's session. With the stolen cookies, a malicious user spoofs the Internet browser and gains access to the application. This allows the hacker to acquire the same level of privileges as the legitimate user.
Session replay—Can occur within a Web application when a user's authentication token is intercepted by attackers and used to bypass the application's authentication controls. If the token is visible through a cookie or a uniform resource locator (URL), the hacker can steal the information and post requests through a hijacked session.
Man-in-the-middle—Refers to intercepting a message, altering its content, then sending it to its original recipient. This is a threat because the hacker can alter the content of the message as desired. In addition, the altered message appears to be legitimate and from someone like a coworker, upper management, or project manager. Therefore, the information is taken seriously and acted upon immediately. If the e-mail recipient responds, the hacker will intercept that message, alter it, and then send it back. Any network request involving client-server communication is subject to man-in-the-middle attacks.
Throughout software development, security must be a consideration. Too often, security measures are considered only after software is developed. A more proactive approach requires that security strategies be incorporated in each phase of application development. Secure code is the highest priority and is a major component in the mitigation of many security risks. With a strong code, hackers cannot inject their own, take advantage of cookies, abuse user inputs, and gain access to your Web application. They cannot gain access to your databases, customer credit cards, employee information, and any other sensitive information.
Many coding errors can lead to vulnerabilities. The U.S. National Security Agency (NSA) released a list of the top 25 coding errors that led to many successful attacks. The top 25 are described in Table 9-1.
Table 9-1. U.S. NSA top 25 coding errors in 2010.
TOP CODING ERRORS | DESCRIPTION |
|---|---|
Failure to preserve Web page structure (aka cross-site scripting) | Cross-site scripting occurs when an attacker injects malicious code into your Web site. Other users visit your Web site expecting trustworthy content but instead code is executed against them. |
Failure to preserve SQL query structure (aka SQL injection) | This mistake allows for SQL injection attacks. Failing to sanitize inputs used in a SQL command allows an attacker to obtain, modify, or delete data throughout the database. |
Cross-site request forgery (CSRF) | Requests from attackers are sent to your site on behalf of a user, often without the user being aware. Fulfilled requests might return malware, masquerading as a response from you. |
Unrestricted upload of file with dangerous type | Data is accepted without first confirming suitability. |
Failure to preserve OS command structure (aka OS command injection) | This attack allows untrusted input to modify a command on your system. Without any validation or sanitization, that command may launch a program with the parameters of your attacker's choice. |
Information exposure through an error message | Error messages intending to be helpful provide too much information. |
URL redirection to untrusted site (aka open redirect) | Users are unknowingly redirected to a malicious and untrusted site. |
Race condition | Poorly written code sends the processor into a panic, consuming all resources, ending as a denial of service. |
Buffer copy without checking size of input (classic buffer overflow) | A buffer overflow occurs when a program attempts to put more data in a buffer than it can hold. The result is a downed or compromised application. |
Improper control of file name for include/require statement in PHP program (aka PHP file inclusion) | Specific to the PHP language, PHP file inclusion occurs when a program does not adequately sanitize and filter input, allowing an attacker to potentially execute code on a remote system. |
Improper limitation of a path name to a restricted directory (aka path traversal) | Path traversal occurs when external input is used to create a path name that is intended to identify a file or directory that is located underneath a restricted parent directory. Using common syntax elements such as .. and /, attackers are able to find directories not intended to be seen. |
Buffer access with incorrect length value | Sometimes occurring with languages such as C and C++, it is a buffer overflow attack in which input with an incorrect value length is written to a buffer that is outside regular memory space. As with other buffer flow attacks, the result may be crashes or the ability to run malicious code. |
Improper check for unusual or exceptional conditions | The application does not account for unexpected or unusual conditions and is not written in a manner to manage them. This can occur in development if conditions that an application may encounter in live production are not considered. |
Improper validation of array index Cross-site request forgery (CSRF) | This is another form of input validation attack. In this case, when a program allows user input to control the array index, there is a chance of array index going out of bound. An array is a special type of variable that stores list-style data types. |
Integer overflow or wraparound | The result of exceeding the integer boundary can lead to undefined and unpredictable outcomes such as crashes. Additionally, integer overflows can result in buffer overflows and can be used to execute malicious code. Integer overflows were discussed in Chapter 7. |
Incorrect calculation of buffer size | Buffer size errors occur when the size of the buffer is not properly allocated. If the buffer size calculation is incorrect, a buffer overflow can occur. |
Download of code without integrity check | This type of error occurs when an application fails to verify the legitimacy of code and accepts the code without proper validation. Allowing unverified code to execute could lead to confidentiality, integrity, and availability vulnerabilities. |
Allocation of resources without limits or throttling) | Without placing limitations on resource usage, DoS attacks can occur if an attacker monopolizes resources to the exclusion of others. |
Improper access control (authorization) | Access controls ensure that only those who should have access to resources or applications actually do. Failure to implement strong access controls may result in integrity, availability, and confidentiality vulnerabilities. |
Reliance on untrusted inputs in a security decision | When authentication and authorization security decisions are based on potentially vulnerable areas such as cookies, environment variables, and forms, an attacker may be able to bypass security to gain access. |
Missing encryption of sensitive data | All sensitive data, whether in storage or in transit, needs to be sufficiently secured using encryption protocols. |
Use of hard-coded credentials | Sometimes credentials, such as passwords, are hard-coded into a configuration file or script to allow for inbound authentication or for outbound communication to external components. A vulnerability can occur if an attacker can gain access to the scripts and learn the hard-coded credentials. |
Missing authentication for critical function | All access to critical functions should require authentication. Open access to critical functions may compromise the applications, data, and more. |
Incorrect permission assignment for critical resource | Use the principle of least privilege to restrict those who have access to critical resources. |
Use of a broken or risky cryptographic algorithm | When securing communications, the cryptography method used may be weak or has been compromised in the past. Ensure that the most current and trusted cryptography mechanisms and protocols are used. |
Properly programmed applications can mitigate many of these coding errors. These attacks combined to breach millions of Web sites each year. With knowledge of these attacks, coders can prevent them and help ensure users' data remains safe.
More information on each of these coding errors can be found at http://www.sans.org/top25-programming-errors/.
To help ensure that security strategies are part of the development and deployment of applications, policies provide a security framework for coders and administrators to follow. A policy is a documented plan outlining the goals, procedures, and objectives that guide decisions to a desired outcome. Many technical policies are used in business, including e-mail, Internet, backup, user, and remote access policies.
A business may have policies detailing acceptable use and compliance requirements. A security policy that all companies should have is one aimed at all aspects of security, including Web application vulnerabilities. The policy should include acceptable use, application development guidelines, and penalties for non-compliance. Security policies are an organization's primary document for information security. A well-written and implemented security policy protects information and people in the organization and includes such elements as:
Data security in storage and in transit
Asset inventory and management
End-user security
Physical security
Access control mechanisms
Incident management and reporting
Fault-tolerant measures
Non-compliance consequences
There are many general guidelines for creating security policies, including well-documented ones at http://www.sans.org/security-resources/policies/#primer. Security policies vary by organization and are customized to the organization's security needs. When developing a security policy, a good approach is to answer a few questions:
What are the assets you are trying to protect? Are you using a SQL back-end database? Do you have sensitive data communicated over the Internet? Before creating the security policy, it is important to identify exactly what needs protection.
What are the common vulnerabilities and threats? Armed with research, you can discover known threats, such as XSS and SQL injection. Before developing the policy, it is essential to understand the types of threats you are up against.
What are the mitigation strategies? Once you have identified the common threats, the security policy should include mitigation strategies for those threats. The policy often identifies not only how to apply the strategies but consequences for non-compliance.
When should the security policy be reviewed and updated? A security policy is a dynamic document that is updated periodically to address new vulnerabilities n S and mitigation strategies.
A security policy often also includes:
Authentication policies—The security policy highlights authentication methods to be used, reporting mechanisms if the authentication is compromised, and password policies. The security policy may outline how authentication is managed. For example, it could state that Hypertext Transfer Protocol Secure (HTTPS) is used for all Web communications to the database or that reauthentication is required at specific times.
Access privilege policies—A common security practice is to use the least amount of authorization required for any task. Create user accounts that do not have any more privilege than is required for their duties. Do not create administrator accounts with complete access to the Web application's design and function. Create service access based upon the granted level of privilege. This includes not granting full service access to any one user account. Access policies may be documented in the security policy.
Disclosure of confidential data—The security policy may set how data is handled both in storage and in transit. The worst case for a compromised system is to have confidential, sensitive data exposed. The best way to reduce the risk of your Web application becoming a target of data disclosure is to create policies that remove the risks. Countermeasures to keep data safe include performing role checks before allowing access to tasks that could potentially reveal or compromise sensitive information. Create a strong encryption key that can encode all confidential information that is stored in configuration files and databases.
Incident response—The security policy often identifies procedures to be followed in case of a security breach.
Security policies are an integral part of an organization's overall security strategy. It is important to have a clear idea of what policies look like and what they are designed to do. The following short sample of an actual security policy provides a glimpse into how policies are designed.
Sample Data Confidentiality Policy
1.0 Purpose
The Data Confidentiality Policy is designed to help network users identify what constitutes sensitive data and the data that cannot be disclosed to non-employees or outside the organization without written authorization. The data referenced in this document applies to all information stored or in transit to and from the network.
All network users are required to familiarize themselves with the data access and handling guidelines presented in this policy. The intent is to protect the data integrity and confidentiality of <Organization Name> and to ensure policy compliance is in practice.
2.0 Scope
All <Organization Name> data is categorized into two main classifications:
<Organization Name> Public
<Organization Name> Confidential
Information that has been deemed public by <Organization Name> is general information that in no way compromises operations of <Organization Name>. Information classified as public may be shared outside of the organization. However, anyone who is unsure whether particular data is public must contact the manager before disclosing.
Information that is classified as confidential must be carefully managed by <Organization Name>. Confidential information in the property of <Organization Name> and disclosing of all sensitive data is strictly forbidden.
3.0 Policy
The Confidentiality Policy outlines the procedures for protecting information at various levels. For example, it identifies how the company expects both confidentially classified and publicly classified data to be handled.
3.1 Public data description—General business information, company newsletter data that contains no employee details.
Allowed for viewing—All internal employees and external contractors.
Electronic communication—No restrictions for e-mail or electronic communications.
Storage methods—All data regardless of sensitivity is electronically encrypted and stored. Data is not encrypted in electronic transmissions.
Disposal/Destruction—Data is not sensitive therefore no special disposal techniques are required.
Penalty for deliberate or inadvertent disclosure—Misuse of public data may lead to disciplinary action including termination.
3.2 Confidential data description—Business secrets, financial documents, employee information etc.
Allowed for viewing—Restricted to those who need the data to complete job-related tasks. No unauthorized viewing or access of confidential data.
Electronic communication—All communication via e-mail or other electronic means require encryption both in transit and in the storage location.
Storage methods—Individual access controls are highly recommended for electronic information.
Disposal/Destruction—In specially marked disposal bins on <Organization Name> premises; electronic data should be expunged or cleared. Reliably erase or physically destroy media.
Penalty for deliberate or inadvertent disclosure—Intentional disclosure of sensitive data will lead to immediate dismissal and possible criminal charges.
4.0 Enforcement
Any employee who intentionally sells or distributes company data may be subject to immediate dismissal and a criminal review. Employees who repeatedly disclose sensitive data unintentionally will be terminated unless end-user education can be implemented and proven effective.
This is just a quick overview of some elements in a security policy. In many organizations, the policy is several pages long, covering security aspects in great detail. In most cases, it is the employees' responsibility to familiarize themselves with security and other policies to ensure they are not in violation.
The best way to prevent software from attacks is to build security into the coding framework of your Web application. Many software tools help check, write, and ensure your Web application is secure. Software tools help inexperienced coders analyze the output and resolve security issues. Another advantage to using a software tool is the large database it comes with. Common software tools have knowledge of more than 100 common and uncommon security flaws in Web applications. This helps target issues the developer might be unaware of. No matter how great a software tool may be, however, its weakness can be its inability to follow the logic of your Web application and truly determine if an input value is, in fact, legitimate. They also have many false positives, which the developer would have to sort through manually to determine if they are accurate. Most software tools are beneficial to prevent buffer overflow attacks.
Even with the help of third-party applications, the best way to implement secure code is to follow secure coding guidelines. These guidelines help to deter many of the malicious attacks and commonly exploited security vulnerabilities. The CERT program is a group of security experts who monitor public sources of vulnerability, inform technology experts of the threats, and develop mitigation strategies. CERT has published its top 10 tips for secure coding. These are:
Validate input—As mentioned throughout this book, unvalidated user input is one of the greatest security risks. CERT contends that most vulnerabilities would be reduced if proper input validation mechanisms were used.
Heed compiler warnings—When compiling code, use the compiler's most strict setting. Then take note of each warning provided and eliminate them. This practice ensures the most stable code.
Plan and design for security policies—Application security should not be an afterthought. Rather, it should be considered at each phase of development. This allows for a layered approach to application security.
Keep the coding simple—Often easier said than done, it is important to keep the coding streamlined and simple. Using complex and extra code can lead to difficulty not only in the application's functioning and troubleshooting but also with security. It may be easier for a malicious user to sneak code into a complex written code.
Deny access by default—Often the best security measure is to deny access by default. This is a guilty-until-proven-innocent approach. In this way, everyone is denied access by default until adequate authentication is used. The authentication methods may be multi-layered to ensure only those who should have access actually do.
Use the principle of least privilege—After authentication, security measures need to be employed that restrict authorization and access to resources. The principle of least privilege dictates that users are restricted to necessary permissions and access levels. User access is closely controlled and permissions tightly restricted.
Sanitize data sent to other systems—When data transmissions are sanitized, the communication still occurs but the message is stripped of potentially harmful content. Sanitizing data helps prevent injection attacks.
Use layered security—Software goes through many stages in the software development life cycle. In each phase of development, security strategies can be employed creating a strong, layered security approach.
Use effective quality assurance techniques—There's pressure to get applications to market and release them as soon as possible. Quality assurance may suffer—and so, too, security. Adopting strong quality assurance helps ensure that applications are not released until all aspects, including code, are sufficiently tested.
Adopt a secure coding standard—Documented standards help regulate and standardize coding to ensure it meets security requirements.
Note
CERT® is a registered trademark, and it refers to the federally funded CERT Coordination Center (CERT/CC). CERT/CC is a part of Carnegie Mellon University (CMU). CERT/CC is different from the United States CERT (US-CERT), which coordinates defense and responses to cyber-attacks in the United States. You can learn more about CERT at http://www.cert.org/.
The above list represents general security principles and guidelines for coding. The following sections explore specific coding recommendations.
Hypertext Markup Language (HTML) is a widely used language for creating Web documents. As such, developing strategies and techniques to ensure HTML is secure is essential. Many general guidelines can be used to help ensure HTML is coded and deployed correctly. These include:
Encrypt HTML code—The source code for HTML Web pages is, for the most part, transparent. Internet Explorer, Google Chrome, Firefox, and other browsers allow users to view the source code of the Web page. Some malicious users may use this feature to create identical pages for cross-site forgery attacks or to find areas to input their own malicious code into the HTML. For this reason, some Web page developers go the extra step, using third-party software to encrypt the HTML source code. Third-party software not only can encrypt source code but also can prevent theft of source code, prevent text selection, disable printing of source code, and prevent spam bots from harvesting e-mail addresses from your pages.
Keep the code clean—When creating HTML pages, it is recommended to keep the coding clean and simple. When the coding is complex, there is a greater chance malicious coding can be inserted without notice.
Monitor HTML code—It sounds like a lot of work, but coders should periodically check their source code for changes. It is not necessary to verify each line of code but to track unexpected changes in the size of the code.
Use input validation with HTML forms—Using HTML forms of any kind comes with a security risk. The key to proper coding and techniques when using HTML forms is, once again, to employ appropriate input validation mechanisms.
Validate URLs—Directory traversal attacks leading to open directories may occur if scripts are placed in the URL. The recommendation is to secure the directories and ensure that malicious users are unable to get to sensitive directories.
The JavaScript language has a unique set of security challenges. When designing or writing with JavaScript, it is important to remember to provide a secure environment for executing mobile code. The Java security architecture is designed to protect systems and users from hostile programs and downloads over a network, but it cannot defend against bugs in trusted codes. This means that if trusted JavaScript code is not implemented properly, it can open holes that the platform is designed to allow. In the worst case, computers can be turned into zombie machines where confidential and sensitive data can be exposed, along with many other malicious activities.
Secure coding standards have been created to assist Java developers in creating secure code while avoiding programmer errors. These guidelines are expected to be followed under all circumstances because they ensure that the Java platform is used and implemented accurately. When the guidelines are followed, Java developers create secure end-user applications and applets that can be trusted by users.
The following are fundamental aspects of the JavaScript secure coding standards:
Prefer to have obviously no flaws than no obvious flaws—According to the standards, it is preferred to have obviously no flaws than no obvious flaws. This means that because of how large the JavaScript language is, flaws can easily slip past even the most advanced developer. Attempt to write code that does not require clever logic to understand that it is secure. Write code that is obviously safe. It is highly recommended to follow all the JavaScript secure coding guidelines unless there is a very specific, strong reason not to.
Avoid duplication—The next fundamental guideline is to avoid duplications. This means to avoid duplicating code and data. Duplicating causes too many problems and can lead to unexpected errors within the application. Both code and data tend not to be treated consistently when they are duplicated.
Restrict privileges—Even with well-reviewed code, flaws may exist. Code must be operated with reduced privileges, thus deterring the ability to exploit flaws. In extreme cases, the developer can implement the principle of least privilege. The developer restricts permissions through policy files, causing the application to run in "sandbox mode," unable to execute any dangerous code. The application is then safe for the user.
Establish trust boundaries—Trust boundaries are necessary to allow easy security auditing to be performed efficiently. This means that the Web browser is outside the system for the Web server. Additionally, a Web server should not be within the same system as the Web browser, so that the security behavior of one does not affect the other.
Contain sensitive data—Due to obvious security issues, sensitive data must be contained in a secure manner and must be kept hidden to users who lack the privilege to view it. Certain information, such as Social Security numbers and passwords, are classified as highly sensitive data. This information should not be stored and not kept for any longer than required for application purposes. This information should not be seen even by administrators, should not be recorded in log files, and should not be detectable through searches.
Avoid dynamic SQL—It is a well-known security vulnerability that dynamic SQL including untrusted input are subject to SQL injection.
XML and HTML generation require care—Cross-site scripting is a common security vulnerability in many Web applications. The root cause is input and output that are accepted without validating the input. Examples can be checking for illegal characters and escaping data properly. It is better to use a library that constructs XML or HTML instead of trying to insert escape codes for every field in the document.
Take care of interpreting untrusted code—Code can be hidden in many places within JavaScript. If the source is classified as untrusted, a secure "sandbox" must be constructed to run it. Examples that can potentially run untrusted code are scripts within scripting and allowing of remote code, specified by the remote connection.
Anytime a Web site uses forms and databases, security is a major concern. Common Gateway Interface (CGI) is not a programming language. Instead, it is a standard that enables communication between Web forms and your program. A CGI script can be written in many different programming languages, including C, C++, Perl, Java, ASP, and others. CGI is commonly used on Web sites to create interactive forms, which may include:
Order forms
Contact forms
Surveys
Registration forms
Signup forms
Reservation forms
Mail order forms
Forms such as these have become commonplace on today's Web sites. In most applications, these forms are secure; however, sometimes they are not. Securing Web forms is a critical security consideration for preventing various forms of injection attacks. Key to securing online forms is incorporating strong input validation strategies, using secure communication protocols such as Secure Sockets Layer (SSL) and HTTPS, using password-protected forms, and, if necessary, incorporating a second level of encryption with RSA military-strength encryption.
It can be argued that the databases and the network database servers are the most important elements of a network. Databases store client details, financial information, human resource details, medical data, and much more. Without access to this data, many organizations would cease to function. One such type of database is the SQL database.
Although there are many ways to access a database, the most popular is to use Structured Query Language (SQL). SQL was created by IBM in 1974 and popularized by Oracle in 1979. SQL is designed for database systems that are accessed by a number of users simultaneously. It works on the basis of commands that can be integrated within applications.
The database is normally accessed by a client using a variety of methods. Although the database can be interrogated directly using commands or programming languages, most databases are accessed through a client application, or "front end." Databases themselves are basically systems for storing, retrieving, and managing data. It is up to the client application to access the data and to make it available in the necessary format to users. This approach allows the databases to maintain a level of simplicity that can make them more responsive to requests and queries.
Because of the importance of databases, strategies and techniques are used to protect those servers and back-end databases. Some of these strategies include:
Limiting user access to the database—All user accounts with access to the database should be closely monitored with the principle of least privilege applied. Database access should be guarded and restricted.
Input validation—Web applications use SQL statements that incorporate user-supplied data. If user-supplied data is unsafe and unfiltered, a Web application may be vulnerable to a SQL injection attack. A successful attack will allow the attacker to access, read, delete, and modify the information held within the database and even take control of the server on which the database is operating.
Limit error messages—Error messages can be a form of information attack. Information leakage occurs when a Web site or Web application discloses sensitive information unknowingly. For example, error messages can reveal information about the server, an application, and the network topology that an attacker can use to exploit the system.
Logging and auditing—To help track and monitor access, it is necessary to enable auditing and logging to track events related to the database and database access. Tracking mechanisms can help identify potential security risks.
Encryption protocols—If the database contains highly sensitive data, as most do, it is important to ensure that any communications into and out of the database are secured. You apply this security using secure encryption protocols and strong cryptography procedures.
Physical security—Logical security measures are one form of security strategy whereas physical security measures are another. Physical security measures restrict physical access to database servers, backups, and any other hardware related to the SQL database.
In the software development world, software configuration management (SCM) refers to the mechanisms used to track and control changes in software. This is important because applications in development are dynamic and change over time, and methods are required to control and document these changes. The ability to track and control such changes helps ensure that software development will be successful. Software configuration management tries to bridge this gap by defining a process for change control.
There are many advantages to implementing a SCM system, including:
Prevent unauthorized changes—During development, applications may change significantly; the SCM ensures that these changes are authorized and that application development is unified in its approach.
Greater control—Having a centralized framework for software development allows for greater control of the entire process. With the SCM, software development can follow a plan and developers have greater control over programming efforts.
Ease of management—With centralized tracking efforts, it is easier to manage the development project to ensure all programming follows a specific format.
Quality control—Using SCM, developers follow specific guidelines, ensuring the quality of the project. SCM helps ensure adherence to the organization's development process.
It is best to use a software development configuration management system along with a revision-level tracking process. This is essential in Web application design because it allows the developer to manage and view all changes that occur within the source code of the Web application. Software development configuration will track and control any change within the source code, and a revision-level tracking system will identify which areas have been modified, by whom, and at what time, along with other additional information. These two systems provide a systematic trail of a Web application's modifications.
Revision control is the management of changes to a document, program, or other information stored as a computer file. This process is most commonly used in software development in which a team of people is altering the same file. Each revision is associated with a timestamp and is identified by the person making the change. In coding, revision tracking is any process that provides control over changes to the source code.
To deal with Web application vulnerabilities, it is best to determine and follow the best practices for mitigating risks. Many organizations follow these practices for maintaining Web application security. These are more than recommendations, given the ability of malicious users to circumvent traditional perimeter security measures and access networks and databases through application security holes. Many organizations help recognize and report known vulnerabilities. It is the security administrators' responsibility to be aware of these organizations and their security reports. Chapter 15 discusses some of these key organizations.
Best practices an administrator should adopt day to day to monitor Web application vulnerabilities include:
Incorporate security in development—Web application vulnerabilities must be addressed in the development process. Consider security throughout the stages of application development, from concept to completion.
Train developers—A key strategy to weave security into the development process is to train developers in security programming and concepts. If programmers know about security threats and mitigation strategies, they can incorporate them in all phases of application development.
Incorporate testing standards—One way to mitigate Web vulnerabilities is to test and retest applications before they are released. This may slow down release dates but the end product will be more robust and more secure. Testing should involve attacking the application with known threats to see how it holds up. Additionally, testing should occur periodically after release as a proactive security measure.
Persistent monitoring—One best practice for Web application security is to continually monitor current threats and review whether those threats can be applied to your application. It is essential that security administrators take a proactive, instead of a reactive, approach to Web application security.
Access controls—It is important to restrict access in whole or in part to Web applications to prevent an uncontrolled access. Often, role-based access is used.
Error messaging—Another key way to secure Web applications is to prevent application error messages from falling into the wrong hands. Many error messages reveal too much information that can be used by malicious users to launch an attack.
System and application hardening—Keep applications and systems up to date with the latest security patches and updates.
As much as possible, security administrators need to be proactive, rather than reactive, in securing their applications. To be proactive, keep application patches up to date and keep track of current attacks and how to mitigate them.
Insecure Web applications can quickly undermine a network's security by completely circumventing perimeter security measures. The most secure firewall and perimeter defense systems will not protect users from security holes in applications. For this reason, focusing security efforts behind the firewall is an essential part of security.
Web application security is an involved process requiring both proactive and reactive measures. These measures include developer training, persistent monitoring, access controls, and system hardening. Developing policies and standards for programming is another important part of a security strategy. Policies regulate how programming is done and how programs are accessed and used within an organization.
Software development configuration management provides a way to track and monitor application development. SCM controls the direction of application development.
Common Gateway Interface (CGI)
JavaScript
Sandbox
Session hijacking
Session management
Software configuration management (SCM)
Web application
Before integrating a Web application, a designer must be aware of the associated risks and measures to mitigate those risks.
True
False
Which of the following are primary components of a Web application? (Select three.)
Web server
Application server
Client browser
Database
When a secure Web application is designed, the only aspect that can be manipulated is private access areas.
True
False
A security policy may contain which of the following elements?
Secure coding procedures
Access control mechanisms
Non-compliance consequences
All of the above
B and C only
You are part of programming team developing a Web application. Your manager has implemented tracking mechanisms to ensure all developers work on the application within the same guidelines. What has your manager implemented?
Acceptable use policy
Application-based access control
SCM
Correct usage policy
A malicious user has gained access to the administrator's account and increased the user's account status. This is an example of _____.
Session management defines how systems handle and manage user sessions.
True
False
_____ can occur within a Web application when a user's authentication token is intercepted by the attackers and used to bypass the authentication controls of the application.
Which of the following are fundamental aspects of the JavaScript secure coding standard? (Select two.)
Duplicate code for redundancy
Restrict privileges
Establish trust boundaries
Use Dynamic SQL
You have decided to use several forms in your HTML Web site. Which of the following types of attacks may take advantage of poorly programmed HTML forms?
Social engineering
Injection
Man-in-the-middle
Elevation of privilege
Which of the following should you use to secure online forms?
Input validation
Secure communication protocols
Password protection
All of the above
Error messages can reveal information about a server that an attacker can use to exploit the system.
True
False