User:Afontes - Revision history

Afontes: some edits

2016-04-18T10:38:01Z

some edits

Afontes: /* Threats to HTTP-applications */

2013-03-05T16:00:26Z

‎Threats to HTTP-applications

Afontes: LARGO.2 / HTTP-Applications threat identification and enumeration

2013-03-05T15:59:45Z

LARGO.2 / HTTP-Applications threat identification and enumeration

New page

= 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

@@ Line 1: / Line 1: @@
-= Info =
+Hi,
-LARGO.2 project support page.<br/>
+My name is Antonio Fontes, I am based in Geneva (Switzerland). I've been an active member of OWASP since 2008. My main objective at OWASP is supporting our Swiss national and local chapters and making sure our members get all the support they need to better interact with OWASP.<br/>
-= Objective =
+I also spend some time doing research work on some topics in direct relation with application security. These projects include:
-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)
+* ''Core programming skills'': involves an empirical approach at identifying the core knowledge/skills that developers should learn during their initial training to immediately produce more resilient code. The project started in 2012, field testing with developers started in 2014 and we are collecting feedback to improve the list. The list now contains 9 items. The main project deliverable is a training slides deck that will be made available to teachers and trainers involved in software programming without strong emphasis on security.
-= Next steps =
+You can reach me by e-mail at antonio.fontes@owasp.org or on twitter at @starbuck3000 for more information.

@@ Line 64: / Line 64: @@
 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 ==
+= Threats to HTTP-applications =
 The tentative list below aims at enumerating 2nd level generic threats to which '''all''' HTTP-applications may be/are exposed: