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 ([email protected]) 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