User:Afontes

= Info = LARGO.2 project support page. Note to viewers:
 * Please do not edit this page. Use the discussion tab if necessary (I'm watching this)
 * You can contact me through twitter (@starbuck3000) or email (antonio.fontes@owasp.org) for private inquiries

= Objective = Accelerate and improve the efficiency of the threat modeling activity by submitting an initial list of common (generic) threats to the application. (see LARGO.2 Threat Modeling process)

= Next steps =
 * round 3 review.
 * QA -> compliance match with OWASP Top 10 2010
 * QA -> compliance match with OWASP Top 10 2013
 * QA -> compliance match with OWASP ASVS
 * QA -> compliance match with WASC threat enumeration
 * QA -> compliance match with CWE Top 25
 * round 4 review.
 * for each threat, describe
 * for each threat, identify symptomatic behavior and/or common culprits
 * for each threat, document recommendations to achieve L1-compliance
 * for each threat, document recommendations to achieve L2-mitigation
 * for each threat, document recommendations to achieve L3-detection
 * for each threat, document recommendations to achieve L4-countermeasures
 * round 5 review.
 * release

= Methodology = The identification of generic (non-business related) threats to HTTP-applications can be performed through several methodologies:
 * Attacker-centric (ARC) threat identification: devising threats based on a list of threat agents and their resources/capabilities.
 * Attack-centric (AKC) threat identification: devising threats based on a list of attack techniques known by the industry (i.e.: the Top 10 Web applications security risks, by the Open Web Application Security Project).
 * Attack-pattern-centric (APC) threat identification: devising generic threats to a particular subset of applications, based on the list of fundamental systems intrusion threat patterns (i.e.: injection pattern).
 * Weakness-centric (WEC) threat identification (devising threats based on a list of known software weaknesses (i.e.: Software attacks and weaknesses, by the Web Application Security Consortium)
 * Asset-centric (ASC) threat identification: devising threats based on the actual and perceived value of the components/assets involved in or around the application.
 * Standard or policy-based (STC) threat identification: devising threats based on a pre-defined set of threats.
 * etc.

In the context of L.2 project, the APC process was chosen to identify the list of threats to be considered in all HTTP-based applications.

= Software attack patterns = Software is exposed to five adverse behaviors, either by systems or by direct human interaction, which can be summarized as follows:
 * Pattern 1: observation
 * Pattern 2: tampering
 * Pattern 3: bruteforcing
 * Pattern 4: denial of service
 * Pattern 5: reverse engineering

The attentive reader may argue that the reverse engineering attack pattern is a subset of the observation pattern. While this would be fully accepted under an academical environment, economics of software security required us to differentiate behaviors that rely solely on the simple observation of "things" from cases where the attacker would invest resources (time, money, acquisition of knowledge, licenses or hardware acquisition) in order to understand what she observes.

Observation pattern
The observation pattern includes all threats involving an interception or collection of data whether while in-transit (i.e.: interception of network communications) or at-rest (i.e.: direct access to datastores, configuration settings, etc.).

Tampering pattern
The tampering pattern includes all threats resulting from the client-server query-response architecture pattern, under which an attacker has both the ability to submit forged or tampered queries to the system and to observe its subsequent response (feedback).

Bruteforcing pattern
The bruteforcing pattern includes all threats resulting from an attacker investing resources in submitting a large set of queries that contain discrete variations to one or more components of the system (i.e.: password bruteforcing).

Denial of service pattern
The denial of service pattern includes all threats resulting from the identification of, and interaction with, architecture components, whose invocation or inner-attributes do not solely/exclusively depend on the size of the client population.

Reverse engineering pattern
The reverse engineering pattern includes all threats resulting from careful scrutiny and/or examination of one or more components or assets, that are part of the system and made available to a potential attacker (i.e.: hardware, source code, algorithms, etc.).

= Threats to HTTP-applications = The tentative list below aims at enumerating 2nd level generic threats to which all HTTP-applications may be/are exposed:

-- observation and interception threats Interception, of sensitive data while in transit Interception, of credentials while in transit Observation, of error messages Observation, of HTTP response status codes Observation, of HTTP headers in responses Observation, of session identifiers Observation, of usernames Observation, of authentication error messages Observation, of the account recovery tokens Direct access, to credentials, server-side Direct access, to configuration settings, server-side Direct access, to access control lists, server-side Direct access, to cached objects, client-side Direct access, to cached objects, on a proxy Direct access, to source code -- injection and tampering threats Injection, of invalid data into requests Injection, of filter-evading data into requests Injection, of active client-side data into requests Injection, of invalid or hostile files Injection, of user-generated session identifiers Tampering, of server-side configuration Tampering, of server-side access control lists Tampering, of cookies (non-session) Tampering, of session identifier cookies Tampering, of parameter validation code in responses Tampering, of hidden fields submitted as form-data -- reverse engineering Reverse engineering, of tokens user for session identification Reverse engineering, of tokens used for account recovery Reverse engineering, of cryptographic authentication code Reverse engineering, of symetric encryption code Reverse engineering, of asymetric encryption code Reverse engineering, of parameter sanitization code Reverse engineering, of parameter validation code -- bruteforcing Sequencing, of resource identifiers submitted in requests Bruteforcing, of resource identifiers submitted in requests Bruteforcing, of passwords through the authentication console Bruteforcing, of passwords through the passwords database -- denial of service Lockout, of user accounts Submission, of large inputs (parameters, files, etc.) Submission, of large number of queries without session identifier Susmission, of large number of authenticated sessions Submission, of large values on parameters that induce memory allocation