Apply New Security Controls to the Set of Attack Services for Which There Isn't Sufficient Mitigation

We’ve already examined cross-site request forgery protection: An unpredictable nonce will have to be sent with each authenticated and authorized page. That is the recommended treatment; in this case, attack to mitigation is 1-to-1.

Table 5.6 adds defenses to each of the attack methods that we enumerated in previous ATASM steps. These are the five attacks and their associated attack surfaces (the CAVs) that we believe are applicable to this system, in this organizational context. Table 5.5 summarized attack surfaces with applied attack methods.

Table 5.6 Attacks and Controls

Specific Attack	Attack Surface	System Objective(s)	Control
SQL and LDAP injection	Applications via HTTP	• execute unintended commands • access data without proper authorization	• Design application code such that dynamic requests to LDAP and to databases are built within the application and not received from users • Dynamic input from users, such as user name or item numbers, must be validated to contain only expected characters • Input not matching precisely constrained values must return an error to the user

Table 5.6 Attacks and Controls (Continued)

Specific Attack	Attack Surface	System Objective(s)	Control
Cross-Site Scripting (XSS)	Web server and applications via HTTP	• execute scripts in the victim's browser • hijack user sessions • deface web sites • redirect the user to malicious sites	• Dynamic input from users, such as user name or item numbers, must be validated to contain only expected characters • Input not matching precisely constrained values must return an error to the user • Response generation must clear all scripting tags found within stored content
(exposed) Direct Object References	HTTP responses from applications and application server	manipulate . . . references to access unauthorized data	• Do not use object revealing protocols similar to Java Remote Method Invocation (RMI) in communications with the user's browser • Remove all debugging and coding information from errors and other user content. Errors shown to user must be user-centric, in plain (nontechnical) language • Do not expose any debugging, configuration, or administrative interfaces over customer/public interfaces • Use per user or session indirect object references • Authorize all direct object accesses
Cross-Site Request Forgery (CSRF)	Application server via HTTP (in this case, AppMaker)	• force a logged-on victim's browser to send a forged HTTP request • generate requests . . . [that appear to be] . . . legitimate requests from the victim	Include a nonpredictable nonce in the response to a successful user authentication. Return the nonce for the session with every authenticated response in a hidden field. Before processing an authenticated request, validate the nonce from the user's session
Unvalidated Redirects and Forwards	Web server and applications via HTTP Possibly also the application server	• redirect and forward users to other pages and websites • use untrusted data to determine the destination pages • redirect victims to phishing or malware sites • use forwards to access unauthorized pages	• Simply avoid using redirects and forwards • If used, don't involve user parameters in calculating the destination. This can usually be done • If destination parameters can't be avoided, ensure that the supplied value is valid, and authorized for the user • Employ an indirect reference to URLs between client and server rather than sending the actual value to the user

SQL = Structured Query Language; LDAP = Lightweight Directory Access Protocol.

Source: Data set in italics is from the Open Web Application Security Project (OWASP) (2013). OWASP Top 10 List.⁶

Some of the defenses are programming requirements. For instance, rewriting errors that will be returned to users in plain language easily understood by users and not containing any programming information is something that will have to be programmed into the applications. Likewise, input validation, which is required to prevent the two injection errors, must be done within code.

Contrast the coding defenses with not using an object referencing or serialization protocol (RMI) to prevent direct code references from escaping to the user. This, like building nonces into responses or using no redirects or forwards, is a design issue. The applications making up the Web-Sock-A-Rama store will have to be designed such that redirects are unnecessary, such that appropriate protocols are used for any code that runs in the user’s browser.

Importantly, if you scan through the defenses listed in Table 5.6, you may notice that the usual panoply of security controls don’t appear as treatments. Firewalls aren’t listed. Intrusion prevention systems are not listed. The treatments given are specific to the attacks. That doesn’t mean that firewalls shouldn’t be deployed. They should be! In this step, we are hunting for those security controls or defenses that will interrupt each CAV such that we can significantly lower the probability of success for attackers (or eliminate it, if possible). For this reason, defenses tend to be specific and to the point. In the next step, we will build the entire security posture as a defense-in-depth.