https://wiki.owasp.org/api.php?action=feedcontributions&user=Stephencor&feedformat=atomOWASP - User contributions [en]2024-03-29T10:12:54ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=DRAFT_Denial_of_Service_Cheat_Sheet&diff=233309DRAFT Denial of Service Cheat Sheet2017-09-14T20:47:30Z<p>Stephencor: Additions on global and ISP level remediations</p>
<hr />
<div>= Introduction =<br />
This sheet is focused on providing an overall, common overview with an informative, straight to the point guidance to propose angles on how to battle denial of service (DoS) attacks on different layers. It is by no means complete, however, it should serve as an indicator to inform the reader and to introduce a workable methodology to tackle this issue.<br />
== Fundamentals ==<br />
Considering that anti-DoS approaches are not one-step solutions, it becomes apparent that, for it to be implemented, it’s necessary to involve different profiles within your organization to assess the actual situation and to apply countermeasures accordingly. These profiles are: developers and architects in the area of application and infrastructure.<br />
<br />
Key concepts within information security evolve around criteria or properties such as the CIA triad. The letter ‘A’, which stands for availability, is our focal point. The core essence of a DoS is to affect, by any means, the availability of instances or objects and to eventually render it inaccessible. Thus, for any information system to serve its purpose, it must be available at any time. Hence why every computing system within the interoperability flow must function correctly to achieve that.<br />
<br />
To remain resilient and resistant, it’s imperative - and suggested - to outline and to conduct a thorough analysis on components within your inventory based on functionality, architecture and performance (i.e. application-wise, infrastructure and network related). <br />
[[File:Flow ddos cheatsheet sessions.jpg|thumb]]<br />
The outcome of this research should identify potential causes of a DoS which highlight single point of failures ranging from programming related errors to resource exhaustion..<br />
<br />
From a prevention point of view, it’s important to have a clear picture on how to tackle your appropriate components to address the issue at stake (e.g. bottlenecks, etc.). That’s why a solid understanding of your environment is essential to develop a suitable defence mechanism. These could be aligned with: <br />
# scaling options ('''up''' = inner hardware components, '''out''' = the number of complete components) <br />
# existing conceptual / logical techniques (such as applying redundancy measurements, bulk-heading, etc. - which expands your in-house capabilities)<br />
# a cost analysis applied to your situation<br />
<br />
Within this document we will adhere to a particular guidance structure to illustrate on how to analyse this subject based on your situation. It is by no means a complete approach but we ought to create fundamental blocks which should be utilized to assist you in constructing anti-DoS concepts fitting to your needs.<br />
<br />
== General Categories and Basic Controls ==<br />
In this cheat sheet, we will adhere to the DDOS classification as documented by CERT-EU. The document categorizes the 7 OSI model layers into three main attack categories, namely application, Session and Network. <br />
<br />
TODO add Diagram<br />
<br />
Application attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. Session (or protocol) attacks focus on consuming server resources, or resources of intermediary equipment like firewalls and load-balancers. Network (or volumetric) attacks focus on saturating the bandwidth of the network resource. It is important to understand that each of these three attack categories needs to be considered when designing a DoS resilient solution. <br />
<br />
Note that OSI model layer 1 and 2 are not included in this categorization. In the spirit of providing a complete overview of all DoS type of attacks, we will shortly discuss these layers and how DoS applies to them.<br />
<br />
The physical layer consists of the networking hardware transmission technologies of a network. It is a fundamental layer underlying the logical data structures of the higher-level functions in a network. Typical DoS scenarios are destruction, obstruction, malfunction. An example is a case where a Georgian elderly woman sliced through an underground cable, resulting in loss of internet for the whole of Armenia.<br />
<br />
The data layer is the protocol layer that transfers data between adjacent network nodes in a wide area network (WAN) or between nodes on the same local area network (LAN) segment.<br />
Typical DoS scenarios are MAC flooding (targeting switch MAC tables) and ARP poisoning. <br />
<br />
In MAC flooding attacks, a switch is flooded with packets, each with a different source MAC address. The intention is to consume the limited memory used by a switch to store the MAC and physical port translation table (MAC table). The result is that valid MAC addresses are purged and the switch enters a fail-over mode where it will act as a network hub. All data is then forwarded to all ports, resulting in a data leakage. <br />
TODO impact in relation to DoS<br />
TODO document compact remediation<br />
<br />
In ARP poisoning attacks a malicious actor sends spoofed ARP (Address Resolution Protocol) messages over the wire. The result is that the attacker’s MAC address can be linked to the IP address of a legitimate device on the network. This allows an attacker to intercept, modify or stop data in transit, that was intended for the victim IP address. The ARP protocol is specific to the local area network and could cause a DoS on the wire communication.<br />
<br />
Packet filtering technology can be used to inspect packets in transit to identify and block offending ARP packets. Another approach is to use static ARP tables but they prove difficult to be maintained.<br />
<br />
= Application attacks =<br />
Application layer attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. These attacks do not have to consume the network bandwidth to be effective. Rather they place an operational strain on the application server in such a way that the server becomes unavailable, unusable or non-functional. All attacks exploiting weaknesses on OSI layer 7 protocol stack are generally categorised as application attacks. They are most challenging to identify/mitigate.<br />
<br />
TODO list all attacks per category. Because we cannot map remediations one on one with an attack vector, we will first need to list them before discussing the action points<br />
<br />
'''Slow HTTP''' is a DoS attack type where HTTP requests are send very slow and fragmented, one at a time. Until the HTTP request was fully delivered, the server will keep resources stalled while waiting for the missing incoming data. At one moment, the server will reach the maximum concurrent connection pool, resulting in a DoS. From an attacker’s perspective, slow HTTP attacks are cheap to perform because they require minimal resources.<br />
<br />
Veelgebruikte attack Tools vermelden of buiten scope van een cheat sheet? <br />
<br />
== Software Design Concepts ==<br />
* '''Cheap validation first''': Validation that is cheap in resources should be considered first. More (CPU, memory and bandwidth) expensive validation should be performed afterward. The reason is obvious, we want to reduce impact on these resources as soon as possible.<br />
* '''Graceful Degradation''' is the ability of maintaining functionality when portions of a system or application break. DoS caused by application termination is a widespread problem. Implementing a fault tolerant design enables a system or application to continue its intended operation, possibly at a reduced level, rather than failing completely, when some part of the system fails. Graceful degradation is a core concept to follow during application design phase, in order to limit impact of DoS.<br />
* '''Prevent single point of failure'''<br />
* '''Avoid highly CPU consuming operations'''<br />
* '''Keep Queues short'''<br />
* '''Handle Exceptions'''<br />
* '''Protect overflow and underflow'''<br />
<br />
* '''Threading''': Avoid operations which must wait for completion of large tasks to proceed. Asynchronous operations<br />
* identify resource intensive pages and plan ahead.<br />
== Session ==<br />
* '''Limit server side session time based on inactivity and a final timeout''': (resource exhaustion) While sessions timeout is most of the time discussed in relation to session security and preventing session hijacking, it is also an important measure to prevent resource exhaustion.<br />
* '''Limit session bound information storage:''' the less data is linked to a session, the less burden a user session has on webserver’s performance.<br />
== Input validation ==<br />
* '''Limit file upload size and extensions''' (resource exhaustion) to prevent DoS on file space storage or other web application functions which will use the upload as input (e.g. image resizing, PDF creation, etc.)https://www.owasp.org/index.php/Unrestricted_File_Upload<br />
<br />
* '''Limit total request size''' (resource exhaustion) to make it harder for resource consuming DoS attack to succeed.<br />
* '''Prevent input based resource allocation''' (resource exhaustion). <br />
* '''Prevent input based function and threading interaction''' (resource exhaustion). User input could influence how many times a function needs to be executed, or how intensive the CPU consumption becomes. Depending on (unfiltered) user input for resource allocation could allow a DoS scenario through resource exhaustion. <br />
* '''Input based puzzles''' like captchas or simple math problems are often used to ‘protect’ a web form. They serve a purpose to protect against functionality abuse. The classic example is a webform that will send out an e-mail after posting the request. A captcha could then prevent the mailbox from getting flooded by a malicious attacker or spambot. Notice that this kind of technology will not help defend against DoS attacks.<br />
Access control<br />
* '''Authentication as a means to expose functionality'''<br />
* '''User lockout''' is a scenario where an attacker can take advantage of the application security mechanisms to cause DoS by abusing the login failure.<br />
<br />
= Network attacks =<br />
''TODO (Develop text)'' Attacks where network bandwidth gets saturation. Volumetric in nature. Amplification techniques make these attacks effective.<br />
<br />
''TODO (list attacks)'' NTP amplification, DNS amplification, UDP flooding, TCP flooding<br />
== Network Design Concepts ==<br />
* '''Preventing single point of failure'''<br />
* '''Pooling'''<br />
* '''Caching''' is the concept that data is stored so future requests for that data can be served faster. The more data is served via caching, to more resilient the application becomes to bandwidth exhaustion. <br />
* '''Static resources hosting on a different domain''' will reduce the number of http requests on the web application. Images and JavaScript are typical files that are loaded from a different domain. <br />
<br />
== Rate limiting ==<br />
Rate limiting is the process of controlling traffic rate from and to a server or component. It can be implemented on infrastructure as well as on an application level. Rate limiting can be based on (offending) IPs, on IP blacklists, on geolocation, etc.<br />
* '''Define a minimum ingress data rate limit''', and drop all connections below that rate. Note that of the rate limit is set too low, this could impact clients. Inspect the logs to establish a baseline of genuine traffic rate. (Protection against slow HTTP attacks)<br />
* '''Define an absolute connection timeout'''<br />
* '''Define a maximum ingress data rate limit''', and drop all connections above that rate.<br />
* '''Define a total bandwidth size limit''' to prevent bandwidth exhaustion<br />
* '''Define a load limit''', which specifies the number of users allowed to access any given resource at any given time.<br />
<br />
== ISP-Level remediations: ==<br />
* '''Filter invalid sender addresses using edge routers''', in accordance with <nowiki>RFC 2267</nowiki>, to filter out IP-spoofing attacks done with the goal of bypassing block lists.<br />
* '''Check your ISP services in terms of DDOS beforehand''' (support for multiple internet access points, enough bandwidth (xx-xxx Gbit/s) and special hardware for traffic analysis and defence on application level<br />
<br />
== Global-Level remediations: Commercial cloud filter services: ==<br />
* Consider using a filter service in order to resist larger attacks (up to 500GBit/s)<br />
* '''Filter services''' support different mechanics to filter out malicious or non compliant traffic<br />
* '''Comply with relevant data protection/privacy laws''' - a lot of providers route traffic through USA/UK<br />
<br />
= Related Articles =<br />
[http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_09_DDoS_final.pdf CERT-EU Whitepaper]<br />
<br />
= Authors and Primary Editors =<br />
<br />
Stephen Corbiaux - stephen.corbiaux [at] owasp.org<br />
<br />
Liviu Rombauts - <br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Stephencorhttps://wiki.owasp.org/index.php?title=DRAFT_Denial_of_Service_Cheat_Sheet&diff=233286DRAFT Denial of Service Cheat Sheet2017-09-13T20:31:08Z<p>Stephencor: /* Related Articles */</p>
<hr />
<div>= Introduction =<br />
This sheet is focused on providing an overall, common overview with an informative, straight to the point guidance to propose angles on how to battle denial of service (DoS) attacks on different layers. It is by no means complete, however, it should serve as an indicator to inform the reader and to introduce a workable methodology to tackle this issue.<br />
== Fundamentals ==<br />
Considering that anti-DoS approaches are not one-step solutions, it becomes apparent that, for it to be implemented, it’s necessary to involve different profiles within your organization to assess the actual situation and to apply countermeasures accordingly. These profiles are: developers and architects in the area of application and infrastructure.<br />
<br />
Key concepts within information security evolve around criteria or properties such as the CIA triad. The letter ‘A’, which stands for availability, is our focal point. The core essence of a DoS is to affect, by any means, the availability of instances or objects and to eventually render it inaccessible. Thus, for any information system to serve its purpose, it must be available at any time. Hence why every computing system within the interoperability flow must function correctly to achieve that.<br />
<br />
To remain resilient and resistant, it’s imperative - and suggested - to outline and to conduct a thorough analysis on components within your inventory based on functionality, architecture and performance (i.e. application-wise, infrastructure and network related). <br />
[[File:Flow ddos cheatsheet sessions.jpg|thumb]]<br />
The outcome of this research should identify potential causes of a DoS which highlight single point of failures ranging from programming related errors to resource exhaustion..<br />
<br />
From a prevention point of view, it’s important to have a clear picture on how to tackle your appropriate components to address the issue at stake (e.g. bottlenecks, etc.). That’s why a solid understanding of your environment is essential to develop a suitable defence mechanism. These could be aligned with: <br />
# scaling options ('''up''' = inner hardware components, '''out''' = the number of complete components) <br />
# existing conceptual / logical techniques (such as applying redundancy measurements, bulk-heading, etc. - which expands your in-house capabilities)<br />
# a cost analysis applied to your situation<br />
<br />
Within this document we will adhere to a particular guidance structure to illustrate on how to analyse this subject based on your situation. It is by no means a complete approach but we ought to create fundamental blocks which should be utilized to assist you in constructing anti-DoS concepts fitting to your needs.<br />
<br />
== General Categories and Basic Controls ==<br />
In this cheat sheet, we will adhere to the DDOS classification as documented by CERT-EU. The document categorizes the 7 OSI model layers into three main attack categories, namely application, Session and Network. <br />
<br />
TODO add Diagram<br />
<br />
Application attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. Session (or protocol) attacks focus on consuming server resources, or resources of intermediary equipment like firewalls and load-balancers. Network (or volumetric) attacks focus on saturating the bandwidth of the network resource. It is important to understand that each of these three attack categories needs to be considered when designing a DoS resilient solution. <br />
<br />
Note that OSI model layer 1 and 2 are not included in this categorization. In the spirit of providing a complete overview of all DoS type of attacks, we will shortly discuss these layers and how DoS applies to them.<br />
<br />
The physical layer consists of the networking hardware transmission technologies of a network. It is a fundamental layer underlying the logical data structures of the higher-level functions in a network. Typical DoS scenarios are destruction, obstruction, malfunction. An example is a case where a Georgian elderly woman sliced through an underground cable, resulting in loss of internet for the whole of Armenia.<br />
<br />
The data layer is the protocol layer that transfers data between adjacent network nodes in a wide area network (WAN) or between nodes on the same local area network (LAN) segment.<br />
Typical DoS scenarios are MAC flooding (targeting switch MAC tables) and ARP poisoning. <br />
<br />
In MAC flooding attacks, a switch is flooded with packets, each with a different source MAC address. The intention is to consume the limited memory used by a switch to store the MAC and physical port translation table (MAC table). The result is that valid MAC addresses are purged and the switch enters a fail-over mode where it will act as a network hub. All data is then forwarded to all ports, resulting in a data leakage. <br />
TODO impact in relation to DoS<br />
TODO document compact remediation<br />
<br />
In ARP poisoning attacks a malicious actor sends spoofed ARP (Address Resolution Protocol) messages over the wire. The result is that the attacker’s MAC address can be linked to the IP address of a legitimate device on the network. This allows an attacker to intercept, modify or stop data in transit, that was intended for the victim IP address. The ARP protocol is specific to the local area network and could cause a DoS on the wire communication.<br />
<br />
Packet filtering technology can be used to inspect packets in transit to identify and block offending ARP packets. Another approach is to use static ARP tables but they prove difficult to be maintained.<br />
<br />
= Application attacks =<br />
Application layer attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. These attacks do not have to consume the network bandwidth to be effective. Rather they place an operational strain on the application server in such a way that the server becomes unavailable, unusable or non-functional. All attacks exploiting weaknesses on OSI layer 7 protocol stack are generally categorised as application attacks. They are most challenging to identify/mitigate.<br />
<br />
TODO list all attacks per category. Because we cannot map remediations one on one with an attack vector, we will first need to list them before discussing the action points<br />
<br />
'''Slow HTTP''' is a DoS attack type where HTTP requests are send very slow and fragmented, one at a time. Until the HTTP request was fully delivered, the server will keep resources stalled while waiting for the missing incoming data. At one moment, the server will reach the maximum concurrent connection pool, resulting in a DoS. From an attacker’s perspective, slow HTTP attacks are cheap to perform because they require minimal resources.<br />
<br />
Veelgebruikte attack Tools vermelden of buiten scope van een cheat sheet? <br />
<br />
== Software Design Concepts ==<br />
* '''Cheap validation first''': Validation that is cheap in resources should be considered first. More (CPU, memory and bandwidth) expensive validation should be performed afterward. The reason is obvious, we want to reduce impact on these resources as soon as possible.<br />
* '''Graceful Degradation''' is the ability of maintaining functionality when portions of a system or application break. DoS caused by application termination is a widespread problem. Implementing a fault tolerant design enables a system or application to continue its intended operation, possibly at a reduced level, rather than failing completely, when some part of the system fails. Graceful degradation is a core concept to follow during application design phase, in order to limit impact of DoS.<br />
* '''Prevent single point of failure'''<br />
* '''Avoid highly CPU consuming operations'''<br />
* '''Keep Queues short'''<br />
* '''Handle Exceptions'''<br />
* '''Protect overflow and underflow'''<br />
<br />
* '''Threading''': Avoid operations which must wait for completion of large tasks to proceed. Asynchronous operations<br />
* identify resource intensive pages and plan ahead.<br />
== Session ==<br />
* '''Limit server side session time based on inactivity and a final timeout''': (resource exhaustion) While sessions timeout is most of the time discussed in relation to session security and preventing session hijacking, it is also an important measure to prevent resource exhaustion.<br />
* '''Limit session bound information storage:''' the less data is linked to a session, the less burden a user session has on webserver’s performance.<br />
== Input validation ==<br />
* '''Limit file upload size and extensions''' (resource exhaustion) to prevent DoS on file space storage or other web application functions which will use the upload as input (e.g. image resizing, PDF creation, etc.)https://www.owasp.org/index.php/Unrestricted_File_Upload<br />
<br />
* '''Limit total request size''' (resource exhaustion) to make it harder for resource consuming DoS attack to succeed.<br />
* '''Prevent input based resource allocation''' (resource exhaustion). <br />
* '''Prevent input based function and threading interaction''' (resource exhaustion). User input could influence how many times a function needs to be executed, or how intensive the CPU consumption becomes. Depending on (unfiltered) user input for resource allocation could allow a DoS scenario through resource exhaustion. <br />
* '''Input based puzzles''' like captchas or simple math problems are often used to ‘protect’ a web form. They serve a purpose to protect against functionality abuse. The classic example is a webform that will send out an e-mail after posting the request. A captcha could then prevent the mailbox from getting flooded by a malicious attacker or spambot. Notice that this kind of technology will not help defend against DoS attacks.<br />
Access control<br />
* '''Authentication as a means to expose functionality'''<br />
* '''User lockout''' is a scenario where an attacker can take advantage of the application security mechanisms to cause DoS by abusing the login failure.<br />
<br />
= Network attacks =<br />
''TODO (Develop text)'' Attacks where network bandwidth gets saturation. Volumetric in nature. Amplification techniques make these attacks effective.<br />
<br />
''TODO (list attacks)'' NTP amplification, DNS amplification, UDP flooding, TCP flooding<br />
== Network Design Concepts ==<br />
* '''Preventing single point of failure'''<br />
* '''Pooling'''<br />
* '''Caching''' is the concept that data is stored so future requests for that data can be served faster. The more data is served via caching, to more resilient the application becomes to bandwidth exhaustion. <br />
* '''Static resources hosting on a different domain''' will reduce the number of http requests on the web application. Images and JavaScript are typical files that are loaded from a different domain. <br />
<br />
== Rate limiting ==<br />
Rate limiting is the process of controlling traffic rate from and to a server or component. It can be implemented on infrastructure as well as on an application level. Rate limiting can be based on (offending) IPs, on IP blacklists, on geolocation, etc.<br />
* '''Define a minimum ingress data rate limit''', and drop all connections below that rate. Note that of the rate limit is set too low, this could impact clients. Inspect the logs to establish a baseline of genuine traffic rate. (Protection against slow HTTP attacks)<br />
* '''Define an absolute connection timeout'''<br />
* '''Define a maximum ingress data rate limit''', and drop all connections above that rate.<br />
* '''Define a total bandwidth size limit''' to prevent bandwidth exhaustion<br />
* '''Define a load limit''', which specifies the number of users allowed to access any given resource at any given time.<br />
<br />
= Related Articles =<br />
[http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_09_DDoS_final.pdf CERT-EU Whitepaper]<br />
<br />
= Authors and Primary Editors =<br />
<br />
Stephen Corbiaux - stephen.corbiaux [at] owasp.org<br />
<br />
Liviu Rombauts - <br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Stephencorhttps://wiki.owasp.org/index.php?title=DRAFT_Denial_of_Service_Cheat_Sheet&diff=233285DRAFT Denial of Service Cheat Sheet2017-09-13T20:30:12Z<p>Stephencor: /* Rate limiting */</p>
<hr />
<div>= Introduction =<br />
This sheet is focused on providing an overall, common overview with an informative, straight to the point guidance to propose angles on how to battle denial of service (DoS) attacks on different layers. It is by no means complete, however, it should serve as an indicator to inform the reader and to introduce a workable methodology to tackle this issue.<br />
== Fundamentals ==<br />
Considering that anti-DoS approaches are not one-step solutions, it becomes apparent that, for it to be implemented, it’s necessary to involve different profiles within your organization to assess the actual situation and to apply countermeasures accordingly. These profiles are: developers and architects in the area of application and infrastructure.<br />
<br />
Key concepts within information security evolve around criteria or properties such as the CIA triad. The letter ‘A’, which stands for availability, is our focal point. The core essence of a DoS is to affect, by any means, the availability of instances or objects and to eventually render it inaccessible. Thus, for any information system to serve its purpose, it must be available at any time. Hence why every computing system within the interoperability flow must function correctly to achieve that.<br />
<br />
To remain resilient and resistant, it’s imperative - and suggested - to outline and to conduct a thorough analysis on components within your inventory based on functionality, architecture and performance (i.e. application-wise, infrastructure and network related). <br />
[[File:Flow ddos cheatsheet sessions.jpg|thumb]]<br />
The outcome of this research should identify potential causes of a DoS which highlight single point of failures ranging from programming related errors to resource exhaustion..<br />
<br />
From a prevention point of view, it’s important to have a clear picture on how to tackle your appropriate components to address the issue at stake (e.g. bottlenecks, etc.). That’s why a solid understanding of your environment is essential to develop a suitable defence mechanism. These could be aligned with: <br />
# scaling options ('''up''' = inner hardware components, '''out''' = the number of complete components) <br />
# existing conceptual / logical techniques (such as applying redundancy measurements, bulk-heading, etc. - which expands your in-house capabilities)<br />
# a cost analysis applied to your situation<br />
<br />
Within this document we will adhere to a particular guidance structure to illustrate on how to analyse this subject based on your situation. It is by no means a complete approach but we ought to create fundamental blocks which should be utilized to assist you in constructing anti-DoS concepts fitting to your needs.<br />
<br />
== General Categories and Basic Controls ==<br />
In this cheat sheet, we will adhere to the DDOS classification as documented by CERT-EU. The document categorizes the 7 OSI model layers into three main attack categories, namely application, Session and Network. <br />
<br />
TODO add Diagram<br />
<br />
Application attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. Session (or protocol) attacks focus on consuming server resources, or resources of intermediary equipment like firewalls and load-balancers. Network (or volumetric) attacks focus on saturating the bandwidth of the network resource. It is important to understand that each of these three attack categories needs to be considered when designing a DoS resilient solution. <br />
<br />
Note that OSI model layer 1 and 2 are not included in this categorization. In the spirit of providing a complete overview of all DoS type of attacks, we will shortly discuss these layers and how DoS applies to them.<br />
<br />
The physical layer consists of the networking hardware transmission technologies of a network. It is a fundamental layer underlying the logical data structures of the higher-level functions in a network. Typical DoS scenarios are destruction, obstruction, malfunction. An example is a case where a Georgian elderly woman sliced through an underground cable, resulting in loss of internet for the whole of Armenia.<br />
<br />
The data layer is the protocol layer that transfers data between adjacent network nodes in a wide area network (WAN) or between nodes on the same local area network (LAN) segment.<br />
Typical DoS scenarios are MAC flooding (targeting switch MAC tables) and ARP poisoning. <br />
<br />
In MAC flooding attacks, a switch is flooded with packets, each with a different source MAC address. The intention is to consume the limited memory used by a switch to store the MAC and physical port translation table (MAC table). The result is that valid MAC addresses are purged and the switch enters a fail-over mode where it will act as a network hub. All data is then forwarded to all ports, resulting in a data leakage. <br />
TODO impact in relation to DoS<br />
TODO document compact remediation<br />
<br />
In ARP poisoning attacks a malicious actor sends spoofed ARP (Address Resolution Protocol) messages over the wire. The result is that the attacker’s MAC address can be linked to the IP address of a legitimate device on the network. This allows an attacker to intercept, modify or stop data in transit, that was intended for the victim IP address. The ARP protocol is specific to the local area network and could cause a DoS on the wire communication.<br />
<br />
Packet filtering technology can be used to inspect packets in transit to identify and block offending ARP packets. Another approach is to use static ARP tables but they prove difficult to be maintained.<br />
<br />
= Application attacks =<br />
Application layer attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. These attacks do not have to consume the network bandwidth to be effective. Rather they place an operational strain on the application server in such a way that the server becomes unavailable, unusable or non-functional. All attacks exploiting weaknesses on OSI layer 7 protocol stack are generally categorised as application attacks. They are most challenging to identify/mitigate.<br />
<br />
TODO list all attacks per category. Because we cannot map remediations one on one with an attack vector, we will first need to list them before discussing the action points<br />
<br />
'''Slow HTTP''' is a DoS attack type where HTTP requests are send very slow and fragmented, one at a time. Until the HTTP request was fully delivered, the server will keep resources stalled while waiting for the missing incoming data. At one moment, the server will reach the maximum concurrent connection pool, resulting in a DoS. From an attacker’s perspective, slow HTTP attacks are cheap to perform because they require minimal resources.<br />
<br />
Veelgebruikte attack Tools vermelden of buiten scope van een cheat sheet? <br />
<br />
== Software Design Concepts ==<br />
* '''Cheap validation first''': Validation that is cheap in resources should be considered first. More (CPU, memory and bandwidth) expensive validation should be performed afterward. The reason is obvious, we want to reduce impact on these resources as soon as possible.<br />
* '''Graceful Degradation''' is the ability of maintaining functionality when portions of a system or application break. DoS caused by application termination is a widespread problem. Implementing a fault tolerant design enables a system or application to continue its intended operation, possibly at a reduced level, rather than failing completely, when some part of the system fails. Graceful degradation is a core concept to follow during application design phase, in order to limit impact of DoS.<br />
* '''Prevent single point of failure'''<br />
* '''Avoid highly CPU consuming operations'''<br />
* '''Keep Queues short'''<br />
* '''Handle Exceptions'''<br />
* '''Protect overflow and underflow'''<br />
<br />
* '''Threading''': Avoid operations which must wait for completion of large tasks to proceed. Asynchronous operations<br />
* identify resource intensive pages and plan ahead.<br />
== Session ==<br />
* '''Limit server side session time based on inactivity and a final timeout''': (resource exhaustion) While sessions timeout is most of the time discussed in relation to session security and preventing session hijacking, it is also an important measure to prevent resource exhaustion.<br />
* '''Limit session bound information storage:''' the less data is linked to a session, the less burden a user session has on webserver’s performance.<br />
== Input validation ==<br />
* '''Limit file upload size and extensions''' (resource exhaustion) to prevent DoS on file space storage or other web application functions which will use the upload as input (e.g. image resizing, PDF creation, etc.)https://www.owasp.org/index.php/Unrestricted_File_Upload<br />
<br />
* '''Limit total request size''' (resource exhaustion) to make it harder for resource consuming DoS attack to succeed.<br />
* '''Prevent input based resource allocation''' (resource exhaustion). <br />
* '''Prevent input based function and threading interaction''' (resource exhaustion). User input could influence how many times a function needs to be executed, or how intensive the CPU consumption becomes. Depending on (unfiltered) user input for resource allocation could allow a DoS scenario through resource exhaustion. <br />
* '''Input based puzzles''' like captchas or simple math problems are often used to ‘protect’ a web form. They serve a purpose to protect against functionality abuse. The classic example is a webform that will send out an e-mail after posting the request. A captcha could then prevent the mailbox from getting flooded by a malicious attacker or spambot. Notice that this kind of technology will not help defend against DoS attacks.<br />
Access control<br />
* '''Authentication as a means to expose functionality'''<br />
* '''User lockout''' is a scenario where an attacker can take advantage of the application security mechanisms to cause DoS by abusing the login failure.<br />
<br />
= Network attacks =<br />
''TODO (Develop text)'' Attacks where network bandwidth gets saturation. Volumetric in nature. Amplification techniques make these attacks effective.<br />
<br />
''TODO (list attacks)'' NTP amplification, DNS amplification, UDP flooding, TCP flooding<br />
== Network Design Concepts ==<br />
* '''Preventing single point of failure'''<br />
* '''Pooling'''<br />
* '''Caching''' is the concept that data is stored so future requests for that data can be served faster. The more data is served via caching, to more resilient the application becomes to bandwidth exhaustion. <br />
* '''Static resources hosting on a different domain''' will reduce the number of http requests on the web application. Images and JavaScript are typical files that are loaded from a different domain. <br />
<br />
== Rate limiting ==<br />
Rate limiting is the process of controlling traffic rate from and to a server or component. It can be implemented on infrastructure as well as on an application level. Rate limiting can be based on (offending) IPs, on IP blacklists, on geolocation, etc.<br />
* '''Define a minimum ingress data rate limit''', and drop all connections below that rate. Note that of the rate limit is set too low, this could impact clients. Inspect the logs to establish a baseline of genuine traffic rate. (Protection against slow HTTP attacks)<br />
* '''Define an absolute connection timeout'''<br />
* '''Define a maximum ingress data rate limit''', and drop all connections above that rate.<br />
* '''Define a total bandwidth size limit''' to prevent bandwidth exhaustion<br />
* '''Define a load limit''', which specifies the number of users allowed to access any given resource at any given time.<br />
<br />
== Related Articles ==<br />
[http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_09_DDoS_final.pdf CERT-EU Whitepaper]<br />
<br />
= Authors and Primary Editors =<br />
<br />
Stephen Corbiaux - stephen.corbiaux [at] owasp.org<br />
<br />
Liviu Rombauts - <br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Stephencorhttps://wiki.owasp.org/index.php?title=DRAFT_Denial_of_Service_Cheat_Sheet&diff=233284DRAFT Denial of Service Cheat Sheet2017-09-13T20:29:46Z<p>Stephencor: structure</p>
<hr />
<div>= Introduction =<br />
This sheet is focused on providing an overall, common overview with an informative, straight to the point guidance to propose angles on how to battle denial of service (DoS) attacks on different layers. It is by no means complete, however, it should serve as an indicator to inform the reader and to introduce a workable methodology to tackle this issue.<br />
== Fundamentals ==<br />
Considering that anti-DoS approaches are not one-step solutions, it becomes apparent that, for it to be implemented, it’s necessary to involve different profiles within your organization to assess the actual situation and to apply countermeasures accordingly. These profiles are: developers and architects in the area of application and infrastructure.<br />
<br />
Key concepts within information security evolve around criteria or properties such as the CIA triad. The letter ‘A’, which stands for availability, is our focal point. The core essence of a DoS is to affect, by any means, the availability of instances or objects and to eventually render it inaccessible. Thus, for any information system to serve its purpose, it must be available at any time. Hence why every computing system within the interoperability flow must function correctly to achieve that.<br />
<br />
To remain resilient and resistant, it’s imperative - and suggested - to outline and to conduct a thorough analysis on components within your inventory based on functionality, architecture and performance (i.e. application-wise, infrastructure and network related). <br />
[[File:Flow ddos cheatsheet sessions.jpg|thumb]]<br />
The outcome of this research should identify potential causes of a DoS which highlight single point of failures ranging from programming related errors to resource exhaustion..<br />
<br />
From a prevention point of view, it’s important to have a clear picture on how to tackle your appropriate components to address the issue at stake (e.g. bottlenecks, etc.). That’s why a solid understanding of your environment is essential to develop a suitable defence mechanism. These could be aligned with: <br />
# scaling options ('''up''' = inner hardware components, '''out''' = the number of complete components) <br />
# existing conceptual / logical techniques (such as applying redundancy measurements, bulk-heading, etc. - which expands your in-house capabilities)<br />
# a cost analysis applied to your situation<br />
<br />
Within this document we will adhere to a particular guidance structure to illustrate on how to analyse this subject based on your situation. It is by no means a complete approach but we ought to create fundamental blocks which should be utilized to assist you in constructing anti-DoS concepts fitting to your needs.<br />
<br />
== General Categories and Basic Controls ==<br />
In this cheat sheet, we will adhere to the DDOS classification as documented by CERT-EU. The document categorizes the 7 OSI model layers into three main attack categories, namely application, Session and Network. <br />
<br />
TODO add Diagram<br />
<br />
Application attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. Session (or protocol) attacks focus on consuming server resources, or resources of intermediary equipment like firewalls and load-balancers. Network (or volumetric) attacks focus on saturating the bandwidth of the network resource. It is important to understand that each of these three attack categories needs to be considered when designing a DoS resilient solution. <br />
<br />
Note that OSI model layer 1 and 2 are not included in this categorization. In the spirit of providing a complete overview of all DoS type of attacks, we will shortly discuss these layers and how DoS applies to them.<br />
<br />
The physical layer consists of the networking hardware transmission technologies of a network. It is a fundamental layer underlying the logical data structures of the higher-level functions in a network. Typical DoS scenarios are destruction, obstruction, malfunction. An example is a case where a Georgian elderly woman sliced through an underground cable, resulting in loss of internet for the whole of Armenia.<br />
<br />
The data layer is the protocol layer that transfers data between adjacent network nodes in a wide area network (WAN) or between nodes on the same local area network (LAN) segment.<br />
Typical DoS scenarios are MAC flooding (targeting switch MAC tables) and ARP poisoning. <br />
<br />
In MAC flooding attacks, a switch is flooded with packets, each with a different source MAC address. The intention is to consume the limited memory used by a switch to store the MAC and physical port translation table (MAC table). The result is that valid MAC addresses are purged and the switch enters a fail-over mode where it will act as a network hub. All data is then forwarded to all ports, resulting in a data leakage. <br />
TODO impact in relation to DoS<br />
TODO document compact remediation<br />
<br />
In ARP poisoning attacks a malicious actor sends spoofed ARP (Address Resolution Protocol) messages over the wire. The result is that the attacker’s MAC address can be linked to the IP address of a legitimate device on the network. This allows an attacker to intercept, modify or stop data in transit, that was intended for the victim IP address. The ARP protocol is specific to the local area network and could cause a DoS on the wire communication.<br />
<br />
Packet filtering technology can be used to inspect packets in transit to identify and block offending ARP packets. Another approach is to use static ARP tables but they prove difficult to be maintained.<br />
<br />
= Application attacks =<br />
Application layer attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. These attacks do not have to consume the network bandwidth to be effective. Rather they place an operational strain on the application server in such a way that the server becomes unavailable, unusable or non-functional. All attacks exploiting weaknesses on OSI layer 7 protocol stack are generally categorised as application attacks. They are most challenging to identify/mitigate.<br />
<br />
TODO list all attacks per category. Because we cannot map remediations one on one with an attack vector, we will first need to list them before discussing the action points<br />
<br />
'''Slow HTTP''' is a DoS attack type where HTTP requests are send very slow and fragmented, one at a time. Until the HTTP request was fully delivered, the server will keep resources stalled while waiting for the missing incoming data. At one moment, the server will reach the maximum concurrent connection pool, resulting in a DoS. From an attacker’s perspective, slow HTTP attacks are cheap to perform because they require minimal resources.<br />
<br />
Veelgebruikte attack Tools vermelden of buiten scope van een cheat sheet? <br />
<br />
== Software Design Concepts ==<br />
* '''Cheap validation first''': Validation that is cheap in resources should be considered first. More (CPU, memory and bandwidth) expensive validation should be performed afterward. The reason is obvious, we want to reduce impact on these resources as soon as possible.<br />
* '''Graceful Degradation''' is the ability of maintaining functionality when portions of a system or application break. DoS caused by application termination is a widespread problem. Implementing a fault tolerant design enables a system or application to continue its intended operation, possibly at a reduced level, rather than failing completely, when some part of the system fails. Graceful degradation is a core concept to follow during application design phase, in order to limit impact of DoS.<br />
* '''Prevent single point of failure'''<br />
* '''Avoid highly CPU consuming operations'''<br />
* '''Keep Queues short'''<br />
* '''Handle Exceptions'''<br />
* '''Protect overflow and underflow'''<br />
<br />
* '''Threading''': Avoid operations which must wait for completion of large tasks to proceed. Asynchronous operations<br />
* identify resource intensive pages and plan ahead.<br />
== Session ==<br />
* '''Limit server side session time based on inactivity and a final timeout''': (resource exhaustion) While sessions timeout is most of the time discussed in relation to session security and preventing session hijacking, it is also an important measure to prevent resource exhaustion.<br />
* '''Limit session bound information storage:''' the less data is linked to a session, the less burden a user session has on webserver’s performance.<br />
== Input validation ==<br />
* '''Limit file upload size and extensions''' (resource exhaustion) to prevent DoS on file space storage or other web application functions which will use the upload as input (e.g. image resizing, PDF creation, etc.)https://www.owasp.org/index.php/Unrestricted_File_Upload<br />
<br />
* '''Limit total request size''' (resource exhaustion) to make it harder for resource consuming DoS attack to succeed.<br />
* '''Prevent input based resource allocation''' (resource exhaustion). <br />
* '''Prevent input based function and threading interaction''' (resource exhaustion). User input could influence how many times a function needs to be executed, or how intensive the CPU consumption becomes. Depending on (unfiltered) user input for resource allocation could allow a DoS scenario through resource exhaustion. <br />
* '''Input based puzzles''' like captchas or simple math problems are often used to ‘protect’ a web form. They serve a purpose to protect against functionality abuse. The classic example is a webform that will send out an e-mail after posting the request. A captcha could then prevent the mailbox from getting flooded by a malicious attacker or spambot. Notice that this kind of technology will not help defend against DoS attacks.<br />
Access control<br />
* '''Authentication as a means to expose functionality'''<br />
* '''User lockout''' is a scenario where an attacker can take advantage of the application security mechanisms to cause DoS by abusing the login failure.<br />
<br />
= Network attacks =<br />
''TODO (Develop text)'' Attacks where network bandwidth gets saturation. Volumetric in nature. Amplification techniques make these attacks effective.<br />
<br />
''TODO (list attacks)'' NTP amplification, DNS amplification, UDP flooding, TCP flooding<br />
== Network Design Concepts ==<br />
* '''Preventing single point of failure'''<br />
* '''Pooling'''<br />
* '''Caching''' is the concept that data is stored so future requests for that data can be served faster. The more data is served via caching, to more resilient the application becomes to bandwidth exhaustion. <br />
* '''Static resources hosting on a different domain''' will reduce the number of http requests on the web application. Images and JavaScript are typical files that are loaded from a different domain. <br />
<br />
= Rate limiting =<br />
Rate limiting is the process of controlling traffic rate from and to a server or component. It can be implemented on infrastructure as well as on an application level. Rate limiting can be based on (offending) IPs, on IP blacklists, on geolocation, etc.<br />
* '''Define a minimum ingress data rate limit''', and drop all connections below that rate. Note that of the rate limit is set too low, this could impact clients. Inspect the logs to establish a baseline of genuine traffic rate. (Protection against slow HTTP attacks)<br />
* '''Define an absolute connection timeout'''<br />
* '''Define a maximum ingress data rate limit''', and drop all connections above that rate.<br />
* '''Define a total bandwidth size limit''' to prevent bandwidth exhaustion<br />
* '''Define a load limit''', which specifies the number of users allowed to access any given resource at any given time.<br />
<br />
== Related Articles ==<br />
[http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_09_DDoS_final.pdf CERT-EU Whitepaper]<br />
<br />
= Authors and Primary Editors =<br />
<br />
Stephen Corbiaux - stephen.corbiaux [at] owasp.org<br />
<br />
Liviu Rombauts - <br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Stephencorhttps://wiki.owasp.org/index.php?title=DRAFT_Denial_of_Service_Cheat_Sheet&diff=233283DRAFT Denial of Service Cheat Sheet2017-09-13T20:28:50Z<p>Stephencor: Markup</p>
<hr />
<div>= Introduction =<br />
This sheet is focused on providing an overall, common overview with an informative, straight to the point guidance to propose angles on how to battle denial of service (DoS) attacks on different layers. It is by no means complete, however, it should serve as an indicator to inform the reader and to introduce a workable methodology to tackle this issue.<br />
== Fundamentals ==<br />
Considering that anti-DoS approaches are not one-step solutions, it becomes apparent that, for it to be implemented, it’s necessary to involve different profiles within your organization to assess the actual situation and to apply countermeasures accordingly. These profiles are: developers and architects in the area of application and infrastructure.<br />
<br />
Key concepts within information security evolve around criteria or properties such as the CIA triad. The letter ‘A’, which stands for availability, is our focal point. The core essence of a DoS is to affect, by any means, the availability of instances or objects and to eventually render it inaccessible. Thus, for any information system to serve its purpose, it must be available at any time. Hence why every computing system within the interoperability flow must function correctly to achieve that.<br />
<br />
To remain resilient and resistant, it’s imperative - and suggested - to outline and to conduct a thorough analysis on components within your inventory based on functionality, architecture and performance (i.e. application-wise, infrastructure and network related). <br />
[[File:Flow ddos cheatsheet sessions.jpg|thumb]]<br />
The outcome of this research should identify potential causes of a DoS which highlight single point of failures ranging from programming related errors to resource exhaustion..<br />
<br />
From a prevention point of view, it’s important to have a clear picture on how to tackle your appropriate components to address the issue at stake (e.g. bottlenecks, etc.). That’s why a solid understanding of your environment is essential to develop a suitable defence mechanism. These could be aligned with: <br />
# scaling options ('''up''' = inner hardware components, '''out''' = the number of complete components) <br />
# existing conceptual / logical techniques (such as applying redundancy measurements, bulk-heading, etc. - which expands your in-house capabilities)<br />
# a cost analysis applied to your situation<br />
<br />
Within this document we will adhere to a particular guidance structure to illustrate on how to analyse this subject based on your situation. It is by no means a complete approach but we ought to create fundamental blocks which should be utilized to assist you in constructing anti-DoS concepts fitting to your needs.<br />
<br />
== General Categories and Basic Controls ==<br />
In this cheat sheet, we will adhere to the DDOS classification as documented by CERT-EU. The document categorizes the 7 OSI model layers into three main attack categories, namely application, Session and Network. <br />
<br />
TODO add Diagram<br />
<br />
Application attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. Session (or protocol) attacks focus on consuming server resources, or resources of intermediary equipment like firewalls and load-balancers. Network (or volumetric) attacks focus on saturating the bandwidth of the network resource. It is important to understand that each of these three attack categories needs to be considered when designing a DoS resilient solution. <br />
<br />
Note that OSI model layer 1 and 2 are not included in this categorization. In the spirit of providing a complete overview of all DoS type of attacks, we will shortly discuss these layers and how DoS applies to them.<br />
<br />
The physical layer consists of the networking hardware transmission technologies of a network. It is a fundamental layer underlying the logical data structures of the higher-level functions in a network. Typical DoS scenarios are destruction, obstruction, malfunction. An example is a case where a Georgian elderly woman sliced through an underground cable, resulting in loss of internet for the whole of Armenia.<br />
<br />
The data layer is the protocol layer that transfers data between adjacent network nodes in a wide area network (WAN) or between nodes on the same local area network (LAN) segment.<br />
Typical DoS scenarios are MAC flooding (targeting switch MAC tables) and ARP poisoning. <br />
<br />
In MAC flooding attacks, a switch is flooded with packets, each with a different source MAC address. The intention is to consume the limited memory used by a switch to store the MAC and physical port translation table (MAC table). The result is that valid MAC addresses are purged and the switch enters a fail-over mode where it will act as a network hub. All data is then forwarded to all ports, resulting in a data leakage. <br />
TODO impact in relation to DoS<br />
TODO document compact remediation<br />
<br />
In ARP poisoning attacks a malicious actor sends spoofed ARP (Address Resolution Protocol) messages over the wire. The result is that the attacker’s MAC address can be linked to the IP address of a legitimate device on the network. This allows an attacker to intercept, modify or stop data in transit, that was intended for the victim IP address. The ARP protocol is specific to the local area network and could cause a DoS on the wire communication.<br />
<br />
Packet filtering technology can be used to inspect packets in transit to identify and block offending ARP packets. Another approach is to use static ARP tables but they prove difficult to be maintained.<br />
<br />
= Application attacks =<br />
Application layer attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. These attacks do not have to consume the network bandwidth to be effective. Rather they place an operational strain on the application server in such a way that the server becomes unavailable, unusable or non-functional. All attacks exploiting weaknesses on OSI layer 7 protocol stack are generally categorised as application attacks. They are most challenging to identify/mitigate.<br />
<br />
TODO list all attacks per category. Because we cannot map remediations one on one with an attack vector, we will first need to list them before discussing the action points<br />
<br />
'''Slow HTTP''' is a DoS attack type where HTTP requests are send very slow and fragmented, one at a time. Until the HTTP request was fully delivered, the server will keep resources stalled while waiting for the missing incoming data. At one moment, the server will reach the maximum concurrent connection pool, resulting in a DoS. From an attacker’s perspective, slow HTTP attacks are cheap to perform because they require minimal resources.<br />
<br />
Veelgebruikte attack Tools vermelden of buiten scope van een cheat sheet? <br />
<br />
== Software Design Concepts ==<br />
* '''Cheap validation first''': Validation that is cheap in resources should be considered first. More (CPU, memory and bandwidth) expensive validation should be performed afterward. The reason is obvious, we want to reduce impact on these resources as soon as possible.<br />
* '''Graceful Degradation''' is the ability of maintaining functionality when portions of a system or application break. DoS caused by application termination is a widespread problem. Implementing a fault tolerant design enables a system or application to continue its intended operation, possibly at a reduced level, rather than failing completely, when some part of the system fails. Graceful degradation is a core concept to follow during application design phase, in order to limit impact of DoS.<br />
* '''Prevent single point of failure'''<br />
* '''Avoid highly CPU consuming operations'''<br />
* '''Keep Queues short'''<br />
* '''Handle Exceptions'''<br />
* '''Protect overflow and underflow'''<br />
<br />
* '''Threading''': Avoid operations which must wait for completion of large tasks to proceed. Asynchronous operations<br />
* identify resource intensive pages and plan ahead.<br />
== Session ==<br />
* '''Limit server side session time based on inactivity and a final timeout''': (resource exhaustion) While sessions timeout is most of the time discussed in relation to session security and preventing session hijacking, it is also an important measure to prevent resource exhaustion.<br />
* '''Limit session bound information storage:''' the less data is linked to a session, the less burden a user session has on webserver’s performance.<br />
== Input validation ==<br />
* '''Limit file upload size and extensions''' (resource exhaustion) to prevent DoS on file space storage or other web application functions which will use the upload as input (e.g. image resizing, PDF creation, etc.)https://www.owasp.org/index.php/Unrestricted_File_Upload<br />
<br />
* '''Limit total request size''' (resource exhaustion) to make it harder for resource consuming DoS attack to succeed.<br />
* '''Prevent input based resource allocation''' (resource exhaustion). <br />
* '''Prevent input based function and threading interaction''' (resource exhaustion). User input could influence how many times a function needs to be executed, or how intensive the CPU consumption becomes. Depending on (unfiltered) user input for resource allocation could allow a DoS scenario through resource exhaustion. <br />
* '''Input based puzzles''' like captchas or simple math problems are often used to ‘protect’ a web form. They serve a purpose to protect against functionality abuse. The classic example is a webform that will send out an e-mail after posting the request. A captcha could then prevent the mailbox from getting flooded by a malicious attacker or spambot. Notice that this kind of technology will not help defend against DoS attacks.<br />
Access control<br />
* '''Authentication as a means to expose functionality'''<br />
* '''User lockout''' is a scenario where an attacker can take advantage of the application security mechanisms to cause DoS by abusing the login failure.<br />
<br />
= Network attacks =<br />
''TODO (Develop text)'' Attacks where network bandwidth gets saturation. Volumetric in nature. Amplification techniques make these attacks effective.<br />
<br />
''TODO (list attacks)'' NTP amplification, DNS amplification, UDP flooding, TCP flooding<br />
== Rate limiting ==<br />
Rate limiting is the process of controlling traffic rate from and to a server or component. It can be implemented on infrastructure as well as on an application level. Rate limiting can be based on (offending) IPs, on IP blacklists, on geolocation, etc.<br />
* '''Define a minimum ingress data rate limit''', and drop all connections below that rate. Note that of the rate limit is set too low, this could impact clients. Inspect the logs to establish a baseline of genuine traffic rate. (Protection against slow HTTP attacks)<br />
* '''Define an absolute connection timeout'''<br />
* '''Define a maximum ingress data rate limit''', and drop all connections above that rate.<br />
* '''Define a total bandwidth size limit''' to prevent bandwidth exhaustion<br />
* '''Define a load limit''', which specifies the number of users allowed to access any given resource at any given time.<br />
<br />
== Network Design Concepts ==<br />
* '''Preventing single point of failure'''<br />
* '''Pooling'''<br />
* '''Caching''' is the concept that data is stored so future requests for that data can be served faster. The more data is served via caching, to more resilient the application becomes to bandwidth exhaustion. <br />
* '''Static resources hosting on a different domain''' will reduce the number of http requests on the web application. Images and JavaScript are typical files that are loaded from a different domain. <br />
<br />
= Related Articles =<br />
[http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_09_DDoS_final.pdf CERT-EU Whitepaper]<br />
<br />
= Authors and Primary Editors =<br />
<br />
Stephen Corbiaux - stephen.corbiaux [at] owasp.org<br />
<br />
Liviu Rombauts - <br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
[[Category:Cheatsheets]]</div>Stephencorhttps://wiki.owasp.org/index.php?title=DRAFT_Denial_of_Service_Cheat_Sheet&diff=233282DRAFT Denial of Service Cheat Sheet2017-09-13T20:24:51Z<p>Stephencor: Adding the draft in progress that was developed during the DDOS worksheet sessions in Germany, September 2017</p>
<hr />
<div>= Introduction =<br />
This sheet is focused on providing an overall, common overview with an informative, straight to the point guidance to propose angles on how to battle denial of service (DoS) attacks on different layers. It is by no means complete, however, it should serve as an indicator to inform the reader and to introduce a workable methodology to tackle this issue.<br />
== Fundamentals ==<br />
Considering that anti-DoS approaches are not one-step solutions, it becomes apparent that, for it to be implemented, it’s necessary to involve different profiles within your organization to assess the actual situation and to apply countermeasures accordingly. These profiles are: developers and architects in the area of application and infrastructure.<br />
<br />
Key concepts within information security evolve around criteria or properties such as the CIA triad. The letter ‘A’, which stands for availability, is our focal point. The core essence of a DoS is to affect, by any means, the availability of instances or objects and to eventually render it inaccessible. Thus, for any information system to serve its purpose, it must be available at any time. Hence why every computing system within the interoperability flow must function correctly to achieve that.<br />
<br />
To remain resilient and resistant, it’s imperative - and suggested - to outline and to conduct a thorough analysis on components within your inventory based on functionality, architecture and performance (i.e. application-wise, infrastructure and network related). <br />
[[File:Flow ddos cheatsheet sessions.jpg|thumb]]<br />
The outcome of this research should identify potential causes of a DoS which highlight single point of failures ranging from programming related errors to resource exhaustion..<br />
<br />
From a prevention point of view, it’s important to have a clear picture on how to tackle your appropriate components to address the issue at stake (e.g. bottlenecks, etc.). That’s why a solid understanding of your environment is essential to develop a suitable defence mechanism. These could be aligned with: <br />
# scaling options ('''up''' = inner hardware components, '''out''' = the number of complete components) <br />
# existing conceptual / logical techniques (such as applying redundancy measurements, bulk-heading, etc. - which expands your in-house capabilities)<br />
# a cost analysis applied to your situation<br />
<br />
Within this document we will adhere to a particular guidance structure to illustrate on how to analyse this subject based on your situation. It is by no means a complete approach but we ought to create fundamental blocks which should be utilized to assist you in constructing anti-DoS concepts fitting to your needs.<br />
<br />
== General Categories and Basic Controls ==<br />
In this cheat sheet, we will adhere to the DDOS classification as documented by CERT-EU. The document categorizes the 7 OSI model layers into three main attack categories, namely application, Session and Network. <br />
<br />
TODO add Diagram<br />
<br />
Application attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. Session (or protocol) attacks focus on consuming server resources, or resources of intermediary equipment like firewalls and load-balancers. Network (or volumetric) attacks focus on saturating the bandwidth of the network resource. It is important to understand that each of these three attack categories needs to be considered when designing a DoS resilient solution. <br />
<br />
Note that OSI model layer 1 and 2 are not included in this categorization. In the spirit of providing a complete overview of all DoS type of attacks, we will shortly discuss these layers and how DoS applies to them.<br />
<br />
The physical layer consists of the networking hardware transmission technologies of a network. It is a fundamental layer underlying the logical data structures of the higher-level functions in a network. Typical DoS scenarios are destruction, obstruction, malfunction. An example is a case where a Georgian elderly woman sliced through an underground cable, resulting in loss of internet for the whole of Armenia.<br />
<br />
The data layer is the protocol layer that transfers data between adjacent network nodes in a wide area network (WAN) or between nodes on the same local area network (LAN) segment.<br />
Typical DoS scenarios are MAC flooding (targeting switch MAC tables) and ARP poisoning. <br />
<br />
In MAC flooding attacks, a switch is flooded with packets, each with a different source MAC address. The intention is to consume the limited memory used by a switch to store the MAC and physical port translation table (MAC table). The result is that valid MAC addresses are purged and the switch enters a fail-over mode where it will act as a network hub. All data is then forwarded to all ports, resulting in a data leakage. <br />
TODO impact in relation to DoS<br />
TODO document compact remediation<br />
<br />
In ARP poisoning attacks a malicious actor sends spoofed ARP (Address Resolution Protocol) messages over the wire. The result is that the attacker’s MAC address can be linked to the IP address of a legitimate device on the network. This allows an attacker to intercept, modify or stop data in transit, that was intended for the victim IP address. The ARP protocol is specific to the local area network and could cause a DoS on the wire communication.<br />
<br />
Packet filtering technology can be used to inspect packets in transit to identify and block offending ARP packets. Another approach is to use static ARP tables but they prove difficult to be maintained.<br />
<br />
= Application attacks =<br />
Application layer attacks focus on rendering applications unavailable by exhausting resources or by making it unusable in a functional way. These attacks do not have to consume the network bandwidth to be effective. Rather they place an operational strain on the application server in such a way that the server becomes unavailable, unusable or non-functional. All attacks exploiting weaknesses on OSI layer 7 protocol stack are generally categorised as application attacks. They are most challenging to identify/mitigate.<br />
<br />
TODO list all attacks per category. Because we cannot map remediations one on one with an attack vector, we will first need to list them before discussing the action points<br />
'''Slow HTTP''' is a DoS attack type where HTTP requests are send very slow and fragmented, one at a time. Until the HTTP request was fully delivered, the server will keep resources stalled while waiting for the missing incoming data. At one moment, the server will reach the maximum concurrent connection pool, resulting in a DoS. From an attacker’s perspective, slow HTTP attacks are cheap to perform because they require minimal resources.<br />
<br />
Veelgebruikte attack Tools vermelden of buiten scope van een cheat sheet? <br />
<br />
== Software Design Concepts ==<br />
* '''Cheap validation first''': Validation that is cheap in resources should be considered first. More (CPU, memory and bandwidth) expensive validation should be performed afterward. The reason is obvious, we want to reduce impact on these resources as soo• as possible.<br />
* '''Graceful Degradation''' is the ability of maintaining functionality when portions of a system or application break. DoS caused by application termination is a widespread problem. Implementing a fault tolerant design enables a system or application to continue its intended operation, possibly at a reduced level, rather than failing completely, when some part of the system fails. Graceful degradation is a core concept to follow during application design phase, in order to limit impact of DoS.<br />
* '''Prevent single point of failure'''<br />
* '''Avoid highly CPU consuming operations'''<br />
* '''Keep Queues short'''<br />
* '''Handle Exceptions'''<br />
* '''Protect overflow and underflow'''<br />
<br />
* Threading: Avoid operations which must wait for completion of large tasks to proceed. Asynchronous operations<br />
<br />
It can be insightful to identify resource intensive pages.<br />
== Session ==<br />
* '''Limit server side session time based on inactivity and a final timeout''': (resource exhaustion) While sessions timeout is most of the time discussed in relation to session security and preventing session hijacking, it is also an important measure to prevent resource exhaustion.<br />
* '''Limit session bound information storage'': the less data is linked to a session, the less burden a user session has on webserver’s performance.<br />
== Input validation ==<br />
* '''Limit file upload size and extensions''' (resource exhaustion) to prevent DoS on file space storage or other web application functions which will use the upload as input (e.g. image resizing, PDF creation, etc.)<br />
https://www.owasp.org/index.php/Unrestricted_File_Upload<br />
* '''Limit total request size''' (resource exhaustion) to make it harder for resource consuming DoS attack to succeed.<br />
* '''Prevent input based resource allocation''' (resource exhaustion). <br />
* '''Prevent input based function and threading interaction''' (resource exhaustion). User input could influence how many times a function needs to be executed, or how intensive the CPU consumption becomes. Depending on (unfiltered) user input for resource allocation could allow a DoS scenario through resource exhaustion. <br />
* '''Input based puzzles''' like captchas or simple math problems are often used to ‘protect’ a web form. They serve a purpose to protect against functionality abuse. The classic example is a webform that will send out an e-mail after posting the request. A captcha could then prevent the mailbox from getting flooded by a malicious attacker or spambot. Notice that this kind of technology will not help defend against DoS attacks.<br />
Access control<br />
* '''Authentication as a means to expose functionality'''<br />
* '''User lockout''' is a scenario where an attacker can take advantage of the application security mechanisms to cause DoS by abusing the login failure.<br />
<br />
= Network attacks =<br />
''TODO''<br />
Attacks where network bandwidth gets saturation. <br />
Volumetric in nature. <br />
Amplification techniques make these attacks effective.<br />
<br />
''TODO list attacks''<br />
NTP amplification, DNS amplification, UDP flooding, TCP flooding<br />
== Rate limiting ==<br />
Rate limiting is the process of controlling traffic rate from and to a server or component. It can be implemented on infrastructure as well as on an application level. Rate limiting can be based on (offending) IPs, on IP blacklists, on geolocation, etc.<br />
* '''Define a minimum ingress data rate limit''', and drop all connections below that rate. Note that of the rate limit is set too low, this could impact clients. Inspect the logs to establish a baseline of genuine traffic rate. (Protection against slow HTTP attacks)<br />
* '''Define an absolute connection timeout'''<br />
* '''Define a maximum ingress data rate limit''', and drop all connections above that rate.<br />
* '''Define a total bandwidth size limit''' to prevent bandwidth exhaustion<br />
* '''Define a load limit''', which specifies the number of users allowed to access any given resource at any given time.<br />
<br />
== Network Design Concepts ==<br />
* '''Preventing single point of failure'''<br />
* '''Pooling'''<br />
* '''Caching''' is the concept that data is stored so future requests for that data can be served faster. The more data is served via caching, to more resilient the application becomes to bandwidth exhaustion. <br />
* '''Static resources hosting on a different domain''' will reduce the number of http requests on the web application. Images and JavaScript are typical files that are loaded from a different domain. <br />
<br />
= Related Articles =<br />
[http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_09_DDoS_final.pdf CERT-EU Whitepaper]<br />
<br />
= Authors and Primary Editors =<br />
<br />
Stephen Corbiaux - stephen.corbiaux [at] owasp.org<br />
<br />
Liviu Rombauts - <br />
<br />
= Other Cheatsheets =<br />
<br />
{{Cheatsheet_Navigation_Body}}<br />
<br />
|}<br />
<br />
[[Category:Cheatsheets]]</div>Stephencorhttps://wiki.owasp.org/index.php?title=File:Flow_ddos_cheatsheet_sessions.jpg&diff=233281File:Flow ddos cheatsheet sessions.jpg2017-09-13T19:59:13Z<p>Stephencor: </p>
<hr />
<div>notes</div>Stephencorhttps://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M1&diff=186389Mobile Top 10 2014-M12014-12-03T10:46:35Z<p>Stephencor: Undo revision 186376 by Ruiwangwarm (talk)</p>
<hr />
<div><center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center><br />
{{Top_10_2010:SubsectionColoredTemplate|<center>Weak Server Side Controls</center>||year=2014}}<br />
<br />
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|AVERAGE}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}<br />
{{Top_10_2010:SummaryTableHeaderEndTemplate}}<br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat agents include any entity that acts as a source of untrustworthy input to a backend API service, web service, or traditional web server application. Examples of such entities include: a user, malware, or a vulnerable app on the mobile device.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The attack vectors correspond to the same attack vectors available through the traditional OWASP Top Ten.</td><br />
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In order for this vulnerability to be exploited, the organization must expose a web service or API call that is consumed by the mobile app. The exposed service or API call is implemented using insecure coding techniques that produce an OWASP Top Ten vulnerability within the server. Through the mobile interface, an adversary is able to feed malicious inputs or unexpected sequences of events to the vulnerable endpoint. Hence, the adversary realizes the original OWASP Top Ten vulnerability on the server.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The technical impact of this vulnerability corresponds to the technical impact of the associated vulnerability (defined in the OWASP Top Ten) that the adversary is exploiting via the mobile device.<br />
For example, an adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the mobile device. This corresponds to the OWASP Top Ten A3 - XSS Category with a technical impact of moderate.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The business impact of this vulnerability corresponds to the business impact of the associated vulnerability (defined in the OWASP Top Ten) that the adversary is exploiting via the mobile device.<br />
For example, an adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the mobile device. This corresponds to the OWASP Top Ten A3 - XSS Category's business impacts.</td><br />
{{Top_10_2010:SummaryTableEndTemplate}}<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=2}}<br />
M1 encompasses almost everything that a mobile application can do badly that does not take place on the phone. Which is exactly the argument… should it be listed at all? Don’t we have a Top Ten lists for Web Applications? Don’t we have one for cloud too?<br />
<br />
In fact, we do. If we could be altogether sure that everyone who wanted information on mobile security also stopped by those projects… it would be a perfect world. After two rounds of data collection from some of the world’s top assessment teams, server side issues are so prevalent in mobile applications that we cannot ignore them in the Mobile Top Ten 2014 listing. Experience suggests that several factors have lead to a proliferation of server-side vulnerabilities. These factors include:<br />
<br />
* Rush to market;<br />
* Lack of security knowledge because of the new-ness of the languages;<br />
* Easy access to frameworks that don’t prioritize security;<br />
* Higher than average outsourced development;<br />
* Lower security budgets for mobile applications;<br />
* Assumption that the mobile OS takes full responsibility for security; and <br />
* Weakness due to cross-platform development and compilation.<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=2}}<br />
Secure coding and configuration practices must be used on server-side of the mobile application. For specific vulnerability information, refer to the OWASP Web Top Ten or Cloud Top Ten projects.<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=2}}<br />
<br />
<br />
Below, you can see that there are many risks and vulnerabilities that you must mitigate in order to satisfy M1:<br />
<br />
<br />
<center>[[File:CloudTT_thum.png|border|400px|link=https://www.owasp.org/index.php/Category:OWASP_Cloud_%E2%80%90_10_Project]] [[File:WebTT_thumb.png|border|400px|link=https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project]]</center><br />
<br />
=== The Worst Offenders ===<br />
<br />
Below is a list vulnerability types that OWASP sees most often within mobile applications:<br />
<br />
<br />
;Poor Web Services Hardening<br />
: Logic flaws<br />
:: [https://www.owasp.org/index.php/Testing_for_business_logic_(OWASP-BL-001) Testing for business logic flaws]<br />
:: [https://www.owasp.org/index.php/Business_Logic_Security_Cheat_Sheet Business Logic Security Cheat Sheet]<br />
: Weak Authentication<br />
:: [https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management OWASP Top Ten Broken Authentication Section]<br />
:: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet Authentication Cheat Sheet]<br />
:: [https://www.owasp.org/index.php/Guide_to_Authentication Developers Guide for Authentication]<br />
:: [https://www.owasp.org/index.php/Testing_for_authentication Testing for Authentication]<br />
: Weak or no session management<br />
: Session fixation<br />
: Sensitive data transmitted using GET method<br />
<br />
<br />
; Insecure web server configurations<br />
: Default content<br />
: Administrative interfaces<br />
<br />
<br />
; Injection (SQL, XSS, Command) on both web services and mobile-enabled websites<br />
<br />
; Authentication flaws<br />
<br />
; Session Management flaws<br />
<br />
; Access control vulnerabilities<br />
<br />
; Local and Remote File Includes<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=2}}<br />
References</div>Stephencorhttps://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M7&diff=183444Mobile Top 10 2014-M72014-10-08T07:08:53Z<p>Stephencor: </p>
<hr />
<div><center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center><br />
{{Top_10_2010:SubsectionColoredTemplate|<center>Client Side Injection</center>||year=2014}}<br />
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Impact|MODERATE}}<br />
{{Top_10_2010:SummaryTableHeaderEndTemplate}}<br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider anyone who can send untrusted data to the mobile app, including external users, internal users, the application itself or other malicious apps on the mobile device.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The adversary loads simple text-based attacks that exploit the syntax of the targeted interpreter within the mobile app. Almost any source of data can be an injection vector, including resource files or the application itself.</td><br />
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Client-side injection results in the execution of malicious code on the mobile device via the mobile app. Typically, this malicious code is provided in the form of data that the threat agent inputs to the mobile app through a number of different means. The data is malformed and is processed (like all other data) by the underlying frameworks supporting the mobile app. During processing, this special data is forces a context switch and the framework reinterprets the data as executable code. The code is malicious in nature and executed by the app. In the "best-case" scenario, the code runs with the same scope and access permissions as the user that has unintentionally executed this code. In the worst-case scenario, the code executes with privileged permissions and much greater scope leading to much greater damage potential than in the "best-case" scenario.<br />
<br />
There are other forms of client-side injection that involve direct injection of binary code into the mobile app via binary attacks. This brute-force approach to malicious code execution may lead to even greater potential for damage than data injections. For more information on binary attacks, see M10.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>To properly determine the technical impact, you must threat model the application. Injection attacks such as SQL Injection on mobile devices can be severe if your application deals with more than one user account on a single application or a shared device or paid-for content. Other injection points are meant to overflow applications components but are less likely to achieve a high impact result because of the managed code protections of the application languages.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The business impact of client-side injection is dependent upon the nature of the malicious code executed by the adversary. Typically, malicious code steals sensitive information (passwords; session cookies; personally identifiable information; etc). Hence, the associated business impacts include: <br />
<br />
* Fraud; and <br />
* Privacy Violations.<br />
</td><br />
{{Top_10_2010:SummaryTableEndTemplate}}<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=4}}<br />
<br />
The best way to find out if an application is vulnerable to injection is to identify the sources of input and validate that user/application supplied data is being subject to input validation, disallowing code injection. Checking the code is a fast and accurate way to see if the application is handling data correctly. Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application. Manual penetration testers can confirm these issues by crafting exploits that confirm the vulnerability.<br />
<br />
Since data can come from many sources in mobile applications, it is important to list them delineated by what they are trying to achieve. In general, injection attacks on mobile devices target the following:<br />
<br />
<br />
'''Data on the Device:'''<br />
<br />
* SQL Injection: SQLite (many phones default data storing mechanism) can be subject to injection just like in web applications. The threat of being able to see data using this type of injection is risky when your application houses several different users, paid-for/unlockable content, etc.<br />
* Local File Inclusion: File handling on mobile devices has the same risks as stated above except it pertains to reading files that might be yours to view inside the application directory.<br />
<br />
<br />
'''The Mobile Users Session:'''<br />
* JavaScript Injection (XSS, Etc): The mobile browser is subject to JavaScript injection as well. Usually the mobile browser has access to the mobile applications cookie, which can lead to session theft.<br />
<br />
<br />
'''The Application Interfaces or Functions:'''<br />
* Several application interfaces or language functions can accept data and can be fuzzed to make applications crash. While most of these flaws do not lead to overflows because of the phone’s platforms being managed code, there have been several that have been used as a “userland” exploit in an exploit chain aimed at rooting or jailbreaking devices. <br />
<br />
<br />
'''Binary Code Itself:'''<br />
* Mobile malware or other malicious apps may perform a binary attack against the presentation layer (HTML; JavaScript; Cascading Style Sheets CSS) or the actual binary of the mobile app's executable. These code injections are executed either by the mobile app's framework or the binary itself at run-time.<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=4}}<br />
In general, protecting you application from client side injection requires looking at all the areas your application can receive data from and applying some sort of input validation. In certain cases this is simple but for others it is more complex, see below:<br />
<br />
<br />
'''iOS Specific Best Practices:'''<br />
<br />
<br />
* '''SQLite Injection:''' When designing queries for SQLite be sure that user supplied data is being passed to a parameterized query. This can be spotted by looking for the format specifier used. In general, dangerous user supplied data will be inserted by a “%@” instead of a proper parameterized query specifier of “?”.<br />
* '''JavaScript Injection (XSS, etc):''' Ensure that all UIWebView calls do not execute without proper input validation. Apply filters for dangerous JavaScript characters if possible, using a whitelist over blacklist character policy before rendering. If possible call mobile Safari instead of rending inside of UIWebkit which has access to your application.<br />
* '''Local File Inclusion:''' Use input validation for NSFileManager calls. <br />
* '''XML Injection:''' use libXML2 over NSXMLParser<br />
* '''Format String Injection:''' Several Objective C methods are vulnerable to format string attacks:<br />
** NSLog, [NSString stringWithFormat:], [NSString initWithFormat:], [NSMutableString appendFormat:], [NSAlert informativeTextWithFormat:], [NSPredicate predicateWithFormat:], [NSException format:], NSRunAlertPanel.<br />
** Do not let sources outside of your control, such as user data and messages from other applications or web services, control any part of your format strings.<br />
* '''Classic C Attacks:''' Objective C is a superset of C, avoid using old C functions vulnerable to injection such as: strcat, strcpy, strncat, strncpy, sprint, vsprintf, gets, etc.<br />
<br />
<br />
'''Android Specific Best Practices:'''<br />
<br />
<br />
* '''SQL Injection:''' When dealing with dynamic queries or Content-Providers ensure you are using parameterized queries.<br />
* '''JavaScript Injection (XSS):''' Verify that JavaScript and Plugin support is disabled for any WebViews (usually the default).<br />
* '''Local File Inclusion:''' Verify that File System Access is disabled for any WebViews (webview.getSettings().setAllowFileAccess(false);).<br />
* '''Intent Injection/Fuzzing:''' Verify actions and data are validated via an Intent Filter for all Activities.<br />
<br />
<br />
'''Binary Injection / Modification Prevention for Android and iOS:'''<br />
<br />
<br />
* See M10 for more information on best practices around preventing, detecting, and reacting to binary injection by an adversary.<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=4}}<br />
Classic client-side injection scenarios include the following:<br />
# SQL Injection - Data retrieved from a mobile app's server contains malformed data that results in a local SQL injection within the mobile device's local databases. Local SQL injections may result in local malware injection, information theft, and much more;<br />
# Cross-Application Scripting Attacks - Malicious intents fed from one Android application to another may result in buffer overflows that allow for malicious code execution;<br />
# Cross-Site Script Attacks - Local HTML modifications via malware or other apps results in execution of malicious JavaScript in the presentation layer of the app. This may result in information theft.<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=4}}<br />
[https://developer.apple.com/library/mac/#documentation/security/conceptual/SecureCodingGuide Apple’s Secure Coding Guide]<br />
<br />
[http://blog.fortify.com/blog/2012/07/25/Format-Strings-Is-Objective-C-Objectively-Safer Fortify Software: Format Strings - Is Objective C Objectively Safer?]<br />
<br />
[http://www.youtube.com/watch?v=FJvyLUjbAy0 Ilja Van Sprundel – Auditing iPhone and iPad Applications]<br />
<br />
[http://labs.mwrinfosecurity.com/blog/2012/04/23/adventures-with-android-webviews/ Adventures with Android WebViews]</div>Stephencorhttps://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M9&diff=183443Mobile Top 10 2014-M92014-10-08T07:07:32Z<p>Stephencor: </p>
<hr />
<div><center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center><br />
<center>{{Top_10_2010:SubsectionColoredTemplate|Improper Session Handling||year=2014}}</center><br />
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}<br />
{{Top_10_2010:SummaryTableHeaderEndTemplate}}<br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Anyone or any mobile app with access to HTTP/S traffic, cookie data, etc.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Attack vectors include physical access to the device, and network traffic capture, or malware on the mobile device.</td><br />
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In order to facilitate a stateful transaction between a user and a mobile app's backend servers, mobile apps use session tokens to maintain state over stateless protocols like HTTP or SOAP. To maintain state, the mobile app must first authenticate the user through the backend. In response to successful authentication, the server issues a session cookie to the mobile app. The mobile app adds this cookie to all future service transactions between the mobile app and the server. This allows the server to conveniently enforce authentication and authorization for any service requests issued by the mobile app.<br />
<br />
Improper session handling occurs when the session token is unintentionally shared with the adversary during a subsequent transaction between the mobile app and the backend servers.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>An adversary that has access to the session tokens is able to impersonate the user by submitting the token to the backend server for any sensitive transactions. Hence, the technical impact is dependent upon who is being impersonated and what service is being requested.<br />
<br />
In the worst-case scenario,the adversary is impersonating an administrative user and issuing a request for administrative functionality that is dangerous in nature.<br />
<br />
In the average-case scenario, users lose control of their accounts and who is performing authorized functionality on their behalf.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Improper session handling results in an adversary that can impersonate another user and perform business functionality on their behalf. This may result in:<br />
<br />
* Fraud;<br />
* Information Theft; or<br />
* Business Interruption.<br />
</td><br />
{{Top_10_2010:SummaryTableEndTemplate}}<br />
<br />
<br />
{{Top_10_2010:SubsectionColoredTemplate|Am I Vulnerable To Improper Session Handling?||year=2014}}<br />
This category deals with session handling and the various ways it can be done insecurely.<br />
<br />
Improper Session Handling typically results in the same outcomes as poor authentication. Once you are authenticated and given a session, that session allows one access to the mobile application. Mobile app code must protect user sessions just as carefully as its authentication mechanism.<br />
<br />
Here are some examples of how it is often done improperly:<br />
<br />
==Failure to Invalidate Sessions on the Backend==<br />
<br />
Many developers invalidate sessions on the mobile app and not on the server side, leaving a major window of opportunity for attackers who are using HTTP manipulation tools. Ensure that all session invalidation events are executed on the server side and not just on the mobile app.<br />
<br />
==Lack of Adequate Timeout Protection==<br />
<br />
Any mobile app you create must have adequate timeout protection on the backend components. This helps prevent malicious potential for an unauthorized user to gain access to an existing session and assume the role of that user.<br />
<br />
Good timeout periods vary widely according to the sensitivity of the app, one's own risk profile, etc., but some good guidelines are:<br />
<br />
* 15 minutes for high security applications<br />
* 30 minutes for medium security applications<br />
* 1 hour for low security applications<br />
<br />
There is an increasing trend towards allowing long timeout values on mobile app sessions due to the nature of user interaction with mobile apps. Often, users are doing many things at once when using their mobile apps. Interactions tend to be sporatic, unpredictable, and drawn out over a longer timeframe than with traditional web apps. In some ways, it makes sense that longer timeout sessions are required because the interval between interactions might be longer. However, this increased session timeout window will increase the risk of session stealing if session handling is not done properly. It is important to raise this risk with the powers-that-be to ensure that session handling is handled properly.<br />
<br />
==Failure to Properly Rotate Cookies==<br />
<br />
Another major problem with session management implementations is the failure to properly reset cookies during authentication state changes. Authentication state changes include events like:<br />
<br />
* Switching from an anonymous user to a logged in user<br />
* Switching from any logged in user to another logged in user<br />
* Switching from a regular user to a privileged user<br />
* Timeouts<br />
<br />
For each of these event types, it is critical that sessions are destroyed on the server side and that the cookies presented as part of the previous sessions are no longer accepted. Ideally, your application would even detect any use of said cookies and would report that to the appropriate security team.<br />
<br />
==Insecure Token Creation==<br />
<br />
In addition to properly invalidating tokens (on the server side) during key application events, it's also crucial that the tokens themselves are generated properly. Just as with encryption algorithms, developers should use well-established and industry-standard methods of created tokens. They should be sufficiently long, complex, and pseudo-random so as to be resistant to guessing/anticipation attacks.<br />
<br />
{{Top_10_2010:SubsectionColoredTemplate|How Do I Prevent Improper Session Handling?||year=2014}}<br />
To handle sessions properly, ensure that mobile app code creates, maintains, and destroys session tokens properly over the life-cycle of a user's mobile app session. Follow the advice above.<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=2}}</div>Stephencorhttps://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M6&diff=183442Mobile Top 10 2014-M62014-10-08T07:06:25Z<p>Stephencor: </p>
<hr />
<div><center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center><br />
{{Top_10_2010:SubsectionColoredTemplate|<center>Broken Cryptography</center>||year=2014}}<br />
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}<br />
{{Top_10_2010:SummaryTableHeaderEndTemplate}}<br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat agents include the following: anyone with physical access to data that has been encrypted improperly, or mobile malware acting on an adversary's behalf.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Attack vectors include the following: decryption of data via physical access to the device or network traffic capture, or malicious apps on the device with access to the encrypted data.</td><br />
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In order to exploit this weakness, an adversary must successfully return encrypted code or sensitive data to its original unencrypted form due to weak encryption algorithms or flaws within the encryption process.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability will result in the unauthorized retrieval of sensitive information from the mobile device.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability can have a number of different business impacts. Typically, broken cryptography will result in the following:<br />
<br />
* Privacy Violations;<br />
* Information Theft;<br />
* Code Theft; <br />
* Intellectual Property Theft; or <br />
* Reputational Damage.<br />
</td><br />
{{Top_10_2010:SummaryTableEndTemplate}}<br />
<br />
<br />
{{Top_10_2010:SubsectionColoredTemplate|Am I Vulnerable to Broken Cryptography?||year=2014}}<br />
Insecure use of cryptography is common in most mobile apps that leverage encryption. There are two fundamental ways that broken cryptography is manifested within mobile apps. First, the mobile app may use a process behind the encryption / decryption that is fundamentally flawed and can be exploited by the adversary to decrypt sensitive data. Second, the mobile app may implement or leverage an encryption / decryption algorithm that is weak in nature and can be directly decrypted by the adversary. The following subsections explore both of these scenarios in more depth:<br />
<br />
== Reliance Upon Built-In Code Encryption Processes ==<br />
<br />
By default, iOS applications are protected (in theory) from reverse engineering via code encryption. The iOS security model requires that apps be encrypted and signed by trustworthy sources in order to execute in non-jailbroken environments. Upon start-up, the iOS app loader will decrypt the app in memory and proceed to execute the code after its signature has been verified by iOS. This feature, in theory, prevents an attacker from conducting binary attacks against an iOS mobile app.<br />
<br />
Using freely available tools like ClutchMod or GBD, an adversary will download the encrypted app onto their jailbroken device and take a snapshot of the decrypted app once the iOS loader loads it into memory and decrypts it (just before the loader kicks off execution). Once the adversary takes the snapshot and stores it on disk, the adversary can use tools like IDA Pro or Hopper to easily perform static / dynamic analysis of the app and conduct further binary attacks.<br />
<br />
Bypassing built-in code encryption algorithms is trivial at best. Always assume that an adversary will be able to bypass any built-in code encryption offered by the underlying mobile OS.<br />
For more information about additional steps you can take to provide additional layers of reverse engineering prevention, see M10.<br />
<br />
== Poor Key Management Processes == <br />
<br />
The best algorithms don't matter if you mishandle your keys. Many make the mistake of using the correct encryption algorithm, but implementing their own protocol for employing it. Some examples of problems here include:<br />
<br />
* Including the keys in the same attacker-readable directory as the encrypted content;<br />
* Making the keys otherwise available to the attacker;<br />
* Avoid the use of hardcoded keys within your binary; and<br />
* Keys may be intercepted via binary attacks. See M10 for more information on preventing binary attacks.<br />
<br />
==Creation and Use of Custom Encryption Protocols==<br />
<br />
There is no easier way to mishandle encryption--mobile or otherwise--than to try to create and use your own encryption algorithms or protocols.<br />
<br />
Always use modern algorithms that are accepted as strong by the security community, and whenever possible leverage the state of the art encryption APIs within your mobile platform. Binary attacks may result in adversary identifying the common libraries you have used along with any hardcoded keys in the binary. In cases of very high security requirements around encryption, you should strongly consider the use of whitebox cryptography. See M10 for more information on preventing binary attacks that could lead to the exploitation of common libraries.<br />
<br />
==Use of Insecure and/or Deprecated Algorithms==<br />
<br />
Many cryptographic algorithms and protocols should not be used because they have been shown to have significant weaknesses or are otherwise insufficient for modern security requirements. These include:<br />
<br />
* RC2<br />
* MD4<br />
* MD5<br />
* SHA1<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=2}}</div>Stephencorhttps://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M5&diff=183441Mobile Top 10 2014-M52014-10-08T07:05:30Z<p>Stephencor: </p>
<hr />
<div><center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center><br />
{{Top_10_2010:SubsectionColoredTemplate|<center>Poor Authorization and Authentication</center>||year=2014}}<br />
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}<br />
{{Top_10_2010:SummaryTableHeaderEndTemplate}}<br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat agents that exploit authentication vulnerabilities typically do so through automated attacks that use available or custom-built tools.<br />
<br />
Threat agents that exploit authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Once the adversary understands how the authentication scheme is vulnerable, they fake or bypass authentication by submitting service requests to the mobile app's backend server and bypass any direct interaction with the moblie app. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.<br />
<br />
Once the adversary understands how the authorization scheme is vulnerable, they fake or bypass authorization by submitting service requests to the mobile app's backend server using a session that belongs to a user with less permission than they should have to conduct the operation. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.</td><br />
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Poor or missing authentication schemes allow an adversary to anonymously execute functionality within the mobile app or backend server used by the mobile app. Weaker authentication for mobile apps is fairly prevalent due to a mobile device's input form factor. The form factor highly encourages short passwords that are often purely based on 4-digit PINs.<br />
<br />
Authentication requirements for mobile apps can be quite different to traditional web authentication schemes due to availability requirements.<br />
<br />
In traditional web apps, users are expected to be online and authenticate in real-time with a backend server. Throughout their session, there is a reasonable expectation that they will have continuous access to the Internet.<br />
<br />
In mobile apps, users are not expected to be online at all times during their session. Mobile internet connections are much less reliable or predictable than traditional web connections. Hence, mobile apps may have uptime requirements that require offline authentication. This offline requirement can have profound ramifications on things that developers must consider when implementing mobile authentication.<br />
<br />
To detect poor authentication schemes, testers can perform binary attacks against the mobile app while it is in 'offline' mode. Through the attack, the tester will force the app to bypass offline authentication and then execute functionality that should require offline authentication (for more information on binary attacks, see M10). As well, testers should try to execute any backend server functionality anonymously by removing any session tokens from any POST/GET requests for the mobile app functionality.<br />
<br />
To test for poor authorization schemes, testers can perform binary attacks against the mobile app and try to execute privileged functionality that should only be executable with a user of higher privilege while the mobile app is in 'offline' mode (for more information on binary attacks, see M10). As well, testers should try to execute any privileged functionality using a low-privilege session token within the corresponding POST/GET requests for the sensitive functionality to the backend server.Poor or missing authorization schemes allow an adversary to execute functionality they should not be entitled to using an authenticated but lower- privilege user of the mobile app. Authorization requirements are more vulnerable when making authorization decisions within the mobile device instead of through a remote server. This may be a requirement due to mobile requirements of offline usability.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The technical impact of poor authentication is that the solution is unable to identify the user performing an action request. Immediately, the solution will be unable to log or audit user activity because the identity of the user cannot be established. This will contribute to an inability to detect the source of an attack, the nature of any underlying exploits, or how to prevent future attacks.<br />
<br />
Authentication failures may expose underlying authorization failures as well. When authentication controls fail, the solution is unable to verify the user's identity. This identity is linked to a user's role and associated permissions. If an attacker is able to anonymously execute sensitive functionality, it highlights that the underlying code is not verifying the permissions of the user issuing the request for the action. Hence, anonymous execution of code highlights failures in both authentication and authorization controls.<br />
<br />
The technical impact of poor authorization is similar in nature to the technical impact of poor authentication. The technical impact can be wide ranging in nature and dependent upon the nature of the over-privileged functionality that is executed. For example, over-privileged execution of remote or local administration functionality may result in destruction of systems or access to sensitive information.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The business impact of poor authentication will typically result in the following at a minimum:<br />
<br />
* Reputational Damage<br />
<br />
In the event that a user (anonymous or verified) is able to execute over-privileged functionality, the business may experience the following impacts:<br />
<br />
* Reputational Damage;<br />
* Fraud; or <br />
* Information Theft.<br />
</td><br />
{{Top_10_2010:SummaryTableEndTemplate}}<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=5}}<br />
Avoid the following Insecure Mobile Application Authentication Design Patterns:<br />
<br />
* If you are porting a web application to its mobile equivalent, authentication requirements of mobile applications should match that of the web application component. Therefore, it should not be possible to authenticate with less authentication factors than the web browser.<br />
* Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data locally, the authentication routine can be bypassed on jailbroken devices through run-time manipulation or modification of the binary. If there is a compelling business requirement for offline authentication, see M10 for additional guidance on preventing binary attacks against the mobile app.<br />
* Where possible, ensure that all authentication requests are performed server-side. Upon successful authentication, application data will be loaded onto the mobile device. This will ensure that application data will only be available after successful authentication.<br />
* If client-side storage of data is required, the data will need to be encrypted using an encryption key that is securely derived from the user’s login credentials. This will ensure that the stored application data will only be accessible upon successfully entering the correct credentials. There are additional risks that the data will be decrypted via binary attacks. See M10 for additional guidance on preventing binary attacks that lead to local data theft.<br />
* Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device.<br />
* Ideally, mobile applications should utilize a device-specific authentication token that can be revoked within the mobile application by the user. This will ensure that the app can mitigate unauthorized access from a stolen/lost device.<br />
* Do not use any spoof-able values for authenticating a user. This includes device identifiers or geo-location.<br />
* Persistent authentication within mobile applications should be implemented as opt-in and not be enabled by default.<br />
* If possible, do not allow users to provide 4-digit PIN numbers for authentication passwords.<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=5}}<br />
Developers should assume all client-side authorization and authentication controls can be bypassed by malicious users. Authorization and authentication controls must be re-enforced on the server-side whenever possible.<br />
<br />
Due to offline usage requirements, mobile apps may be required to perform local authentication or authorization checks within the mobile app's code. If this is the case, developers should instrument local integrity checks within their code to detect any unauthorized code changes. See M10 for more information about detecting and reacting to binary attacks.<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=5}}<br />
The following scenarios showcase weak authentication or authorization controls in mobile apps:<br />
<br />
# Developers assume that only authenticated users will be able to generate a service request that the mobile app submits to its backend for processing. During the processing of the request, the server code does not verify that the incoming request is associated with a known user. Hence, adversaries submit service requests to the back-end service and anonymously execute functionality that affects legitimate users of the solution.<br />
# Developers assume that only authorized users will be able to see the existance of a particular function on their mobile app. Hence, they expect that only legitimately authorized users will be able to issue the request for the service from their mobile device. Backend code that processes the request does not bother to verify that the identity associated with the request is entitled to execute the service. Hence, adversaries are able to perform remote administrative functionality using fairly low-privilege user accounts.<br />
# Due to usability requirements, mobile apps allow for passwords that are 4 digits long. Server code correctly stores a hashed version of the password. However, due to the severely short length of the password, an adversary will be able to quickly deduce the original passwords using rainbow hash tables. If the password file (or data store) on the server is compromised, an adversary will be able to quickly deduce users' passwords.<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=5}}</div>Stephencorhttps://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M4&diff=183440Mobile Top 10 2014-M42014-10-08T07:03:29Z<p>Stephencor: </p>
<hr />
<div><center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center><br />
{{Top_10_2010:SubsectionColoredTemplate|<center>Unintended Data Leakage</center>||year=2014}}<br />
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}<br />
{{Top_10_2010:SummaryTableHeaderEndTemplate}}<br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Agents that may exploit this vulnerability include the following: mobile malware, modified versions of legitimate apps, or an adversary that has physical access to the victim's mobile device.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>An agent that has physical access to the device will use freely available forensic tools to conduct the attack. An agent that has access to the device via malicious code will use fully permissible and documented API calls to conduct this attack.</td><br />
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Unintended data leakage occurs when a developer inadvertently places sensitive information or data in a location on the mobile device that is easily accessible by other apps on the device. First, a developer's code processes sensitive information supplied by the user or the backend. During that processing, a side-effect (that is unknown to the developer) results in that information being placed into an insecure location on the mobile device that other apps on the device may have open access to. Typically, these side-effects originate from the underlying mobile device's operating system (OS). This will be a very prevalent vulnerability for code produced by a developer that does not have intimate knowledge of how that information can be stored or processed by the underlying OS.<br />
<br />
It is easy to detect data leakage by inspecting all mobile device locations that are accessible to all apps for the app's sensitive information.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability may result in the following technical impacts: extraction of the app's sensitive information via mobile malware, modified apps, or forensic tools.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The nature of the business impact is highly dependent upon the nature of the information stolen. Sensitive information theft may result in the following business impacts:<br />
<br />
* Privacy Violations<br />
* PCI Violations<br />
* Reputational Damage; or <br />
* Fraud.</td><br />
{{Top_10_2010:SummaryTableEndTemplate}}<br />
<br />
{{Top_10_2010:SubsectionColoredTemplate|Am I Vulnerable to Unintended Data Leakage?||year=2014}}<br />
Unintended data leakage (formerly side-channel data leakage) includes vulnerabilities from the OS, frameworks, compiler environment, new hardware, etc. without a developers knowledge. <br />
<br />
In mobile development, this is most seen in undocumented (or under-documented) internal processes such as:<br />
<br />
* The way the OS caches data, images, key-presses, logging, and buffers.<br />
* The way the development framework caches data, images, key-presses, logging, and buffers.<br />
* The way or amount of data ad, analytic, social, or enablement frameworks cache data, images, key-presses, logging, and buffers.<br />
<br />
{{Top_10_2010:SubsectionColoredTemplate|How Do I Prevent Unintended Data Leakage?||year=2014}}<br />
It is important to threat model your OS, platforms, and frameworks, to see how they handle the following types of features:<br />
<br />
* URL Caching (Both request and response)<br />
* Keyboard Press Caching<br />
* Copy/Paste buffer Caching<br />
* Application backgrounding<br />
* Logging<br />
* HTML5 data storage<br />
* Browser cookie objects<br />
* Analytics data sent to 3rd parties<br />
<br />
<br />
It is especially important to discern what a given OS or framework does by default. By identifying defaults and applying mitigating controls, you can avoid unintended data leakage.<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=8}}<br />
<br />
==OS: iOS ==<br />
* URL Caching (Both request and response)<br />
* Keyboard Press Caching<br />
* Copy/Paste buffer Caching<br />
* Application backgrounding<br />
* Logging<br />
* HTML5 data storage<br />
* Browser cookie objects<br />
* Analytics data sent to 3rd parties<br />
<br />
==OS: Android ==<br />
* URL Caching (Both request and response)<br />
* Keyboard Press Caching<br />
* Copy/Paste buffer Caching<br />
* Application backgrounding<br />
* Logging<br />
* HTML5 data storage<br />
* Browser cookie objects<br />
* Analytics data sent to 3rd parties<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=8}}<br />
References</div>Stephencorhttps://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M3&diff=183439Mobile Top 10 2014-M32014-10-08T07:02:23Z<p>Stephencor: </p>
<hr />
<div><center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center><br />
{{Top_10_2010:SubsectionColoredTemplate|<center>Insufficient Transport Layer Protection</center>||year=2014}}<br />
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}<br />
{{Top_10_2010:SummaryTableValue-3-Template|Exploitability|DIFFICULT}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Detectability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Impact|MODERATE}}<br />
{{Top_10_2010:SummaryTableHeaderEndTemplate}}<br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>When designing a mobile application, data is commonly exchanged in a client-server fashion. When the solution transmits its data, it must traverse the mobile device's carrier network and the internet. Threat agents might exploit vulnerabilities to intercept sensitive data while it's traveling across the wire. The following threat agents exist:<br />
<br />
* An adversary that shares your local network (compromised or monitored Wi-Fi);<br />
* Carrier or network devices (routers, cell towers, proxy's, etc); or<br />
* Malware on your mobile device.<br />
</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> The exploitabilty factor of monitoring a network for insecure communications ranges. Monitoring traffic over a carrier's network is harder than that of monitoring a local coffee shop's traffic. In general, targeted attacks are easier to perform. </td><br />
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication but not elsewhere. This inconsistency leads to the risk of exposing data and session IDs to interception.<br />
<br />
The use of transport security does not mean the app has implemented it correctly.<br />
<br />
To detect basic flaws, observe the phone's network traffic. More subtle flaws require inspecting the design of the application and the applications configuration. </td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This flaw exposes an individual user's data and can lead to account theft. If the adversary intercepts an admin account, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>At a minimum, interception of sensitive data through a communication channel will result in a privacy violation.<br />
<br />
The violation of a user's confidentiality may result in:<br />
<br />
* Identity theft;<br />
* Fraud, or<br />
* Reputational Damage.</td><br />
{{Top_10_2010:SummaryTableEndTemplate}}<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=3}}<br />
To find out if an application has sufficient transport layer protection, look at the application traffic through a proxy. Answer the following questions:<br />
<br />
# Are all connections, not just ones to servers you own, properly encrypted? <br />
# Are the SSL certificates in date?<br />
# Are the SSL certificates self signed?<br />
# Does the SSL use high enough cipher strengths?<br />
# Will your application accept user accepted certificates as authorities?<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=3}}<br />
'''General Best Practices:'''<br />
<br />
* Assume that the network layer is not secure and is susceptible to eavesdropping. <br />
* Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive information, session tokens, or other sensitive data to a backend API or web service.<br />
* Account for outside entities like third-party analytics companies, social networks, etc. by using their SSL versions when an application runs a routine via the browser/webkit. Avoid mixed SSL sessions as they may expose the user’s session ID.<br />
* Use strong, industry standard cipher suites with appropriate key lengths.<br />
* Use certificates signed by a trusted CA provider. <br />
* Never allow self-signed certificates, and consider certificate pinning for security conscious applications.<br />
* Always require SSL chain verification.<br />
* Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain.<br />
* Alert users through the UI if the mobile app detects an invalid certificate.<br />
* Do not send sensitive data over alternate channels (e.g, SMS, MMS, or notifications).<br />
* If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL channel. In the event that future vulnerabilities are discovered in the SSL implementation, the encrytped data will provide a secondary defense against confidentiality violation.<br />
<br />
Newer threats allow an adversary to eavesdrop on sensitive traffic by intercepting the traffic within the mobile device just before the mobile device's SSL library encrypts and transmits the network traffic to the destination server. See M10 for more information on the nature of this risk.<br />
<br />
'''iOS Specific Best Practices'''<br />
<br />
Default classes in the latest version of iOS handle SSL cipher strength negotiation very well. Trouble comes when developers temporarily add code to bypass these defaults to accommodate development hurdles. In addition to the above general practices:<br />
<br />
* Ensure that certificates are valid and fail closed.<br />
* When using CFNetwork, consider using the Secure Transport API to designate trusted client certificates. In almost all situations, NSStreamSocketSecurityLevelSSLv3 or NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher strength.<br />
* After development, ensure all NSURL calls (or wrappers of NSURL) do not allow self signed or invalid certificates such as the NSURL class method setAllowsAnyHTTPSCertificate.<br />
* Consider using certificate pinning by doing the following: export your certificate, include it in your app bundle, and anchor it to your trust object. Using the NSURL method connection:willSendRequestForAuthenticationChallenge: will now accept your cert.<br />
<br />
<br />
'''Android Specific Best Practices'''<br />
<br />
* Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. These are equivalent to trusting all certificates.<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=3}}<br />
There are a few common scenarios that penetration testers frequently discover when inspecting a mobile app's transport layer security:<br />
<br />
; Lack of Certificate Inspection<br />
: The mobile app and an endpoint successfully connect and perform a SSL/TLS handshake to establish a secure channel. However, the mobile app fails to inspect the certificate offered by the server and the mobile app unconditionally accepts any certificate offered to it by the server. This destroys any mutual authentication capability between the mobile app and the endpoint. The mobile app is susceptible to man-in-the-middle attacks through a SSL proxy<br />
; Weak Handshake Negotiation<br />
: The mobile app and an endpoint successfully connect and negotiate a cipher suite as part of the connection handshake. The client successfully negotiates with the server to use a weak cipher suite that results in weak encryption that can be easily decrypted by the adversary. This jeopardizes the confidentiality of the channel between the mobile app and the endpoint;<br />
; Privacy Information Leakage<br />
: The mobile app transmits personally identifiable information to an endpoint via non-secure channels instead of over SSL. This jeopardizes the confidentiality of any privacy-related data between the mobile app and the endpoint.<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=3}}<br />
* [http://h30499.www3.hp.com/t5/Fortify-Application-Security/Exploring-The-OWASP-Mobile-Top-10-M3-Insufficient-Transport/ba-p/5966473 Fortify On Demand Blog - Exploring The OWASP Mobile Top 10: Insufficient Transport Layer Protection]<br />
* [https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet OWASP ][https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet IOS Developer Cheat Sheet]<br />
* [http://blog.securemacprogramming.com/2011/12/on-ssl-pinning-for-cocoa-touch/ blog.securemacprogramming.com - SSL Pinning for Cocoa Touch]<br />
* [http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security]<br />
* [http://www.hpenterprisesecurity.com/vulncat/en/vulncat/index.html Fortify VulnCat - A Taxonimy of Software Security Errors]</div>Stephencorhttps://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M2&diff=183438Mobile Top 10 2014-M22014-10-08T06:59:24Z<p>Stephencor: </p>
<hr />
<div><center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center><br />
{{Top_10_2010:SubsectionColoredTemplate|<center>Insecure Data Storage</center>||year=2014}}<br />
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}<br />
{{Top_10_2010:SummaryTableHeaderEndTemplate}}<br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threats agents include the following: an adversary that has attained a lost/stolen mobile device; malware or a other repackaged app acting on the adversary's behalf that executes on the mobile device.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In the event that an adversary physically attains the mobile device, the adversaryhooks up the mobile device to a computer with freely available software. These tools allow the adversary to see all third party application directories that often contain stored personally identifiable information (PII) or other sensitive information assets. An adversary may construct malware or modify a legitimate app to steal such information assets.</td><br />
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Insecure data storage, vulnerabilities occurs when development teams assume that users or malware will not have access to a mobile device's filesystem and subsequent sensitive information in data-stores on the device. Filesystems are easily accessible. Organizations should expect a malicious user or malware to inspect sensitive data stores.<br />
<br />
Rooting or jailbreaking a mobile device circumvents any encryption protections. When data is not protected properly, specialized tools are all that is needed to view application data.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Insecure data storage can result in data loss, in the best case, for one user. In the worst case, for many users. Common valuable pieces of data seen stored include: <br />
* Usernames<br />
* Authentication tokens<br />
* Passwords<br />
* Cookies<br />
* Location data<br />
* UDID/EMEI, Device Name, Network Connection Name<br />
* Personal Information: DoB, Address, Social, Credit Card Data<br />
* Application Data: <br />
** Stored application logs<br />
** Debug information<br />
** Cached application messages<br />
** Transaction histories</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Insecure data storage vulnerabilities typically lead to the following business risks for the organization that owns the risk app:<br />
* Identity Theft<br />
* Fraud<br />
* Reputation Damage<br />
* External Policy Violation (PCI)<br />
* or Material Loss.</td><br />
{{Top_10_2010:SummaryTableEndTemplate}}<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=1}}<br />
It is important to threat-model your mobile app to understand the information assets it processes and how the underlying APIs handle those assets. These APIs should store sensitive information securely. Places OWASP most often sees data being stored insecurely include the following:<br />
<br />
* SQLite databases<br />
* Log Files<br />
* Plist Files<br />
* XML Data Stores or Manifest Files<br />
* Binary data stores<br />
* Cookie stores<br />
* SD Card<br />
* Cloud synced<br />
<br />
When applying encryption and decryption to sensitive information assets, malware may perform a binary attack on the app in order to steal encryption or decryption keys. Once it steals the keys, it will decrypt the local data and steal sensitive information. See OWASP Mobile Top Ten 2014 Category M10 for more information on this topic.<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=1}}<br />
The cardinal rule of mobile apps is to not store data unless absolutely necessary. As a developer you have to assume that the data is forfeited as soon as it touches the phone. You also have to consider the implications of losing mobile users' data to a silent jailbreak or root exploit. If the usability versus security trade-off is too much for you, OWASP recommends scrutinizing your platforms data security APIs and making sure you’re calling them appropriately. The lesson here is to know what data is being stored and protect it appropriately.<br />
<br />
<br />
'''iOS Specific Best Practices:'''<br />
* Never store credentials on the phone file system. Force the user to authenticate using a standard web or API login scheme (over HTTPS) to the application upon each opening and ensure session timeouts are set at the bare minimum to meet the user experience requirements.<br />
* Where storage or caching of information is necessary consider using a standard iOS encryption library such as CommonCrypto. However, for particularly sensitive apps, consider using whitebox cryptography solutions that avoid the leakage of binary signatures found within common encryption libraries.<br />
* If the data is small, using the provided apple keychain API is recommended but, once a phone is jailbroken or exploited the keychain can be easily read. This is in addition to the threat of a bruteforce on the devices PIN, which as stated above is trivial in some cases.<br />
* For databases consider using SQLcipher for Sqlite data encryption<br />
* For items stored in the keychain leverage the most secure API designation, kSecAttrAccessibleWhenUnlocked (now the default in iOS 5) and for enterprise managed mobile devices ensure a strong PIN is forced, alphanumeric, larger than 4 characters.<br />
* For larger or more general types of consumer-grade data, Apple’s File Protection mechanism can safely be used (see NSData Class Reference for protection options).<br />
* Avoid using NSUserDefaults to store sensitive pieces of information as it stores data in plist files.<br />
* Be aware that all data/entities using NSManagedObects will be stored in an unencrypted database file.<br />
* Avoid exclusively relying upon hardcoded encryption or decryption keys when storing sensitive information assets.<br />
* Consider providing an additional layer of encryption beyond any default encryption mechanisms provided by the operating system.<br />
<br />
<br />
'''Android Specific Best Practices:'''<br />
* For local storage the enterprise android device administration API can be used to force encryption to local file-stores using “setStorageEncryption”<br />
* For SD Card Storage some security can be achieved via the ‘javax.crypto’ library. You have a few options, but an easy one is simply to encrypt any plain text data with a master password and AES 128.<br />
* Ensure any shared preferences properties are '''NOT''' MODE_WORLD_READABLE unless explicitly required for information sharing between apps.<br />
* Avoid exclusively relying upon hardcoded encryption or decryption keys when storing sensitive information assets.<br />
* Consider providing an additional layer of encryption beyond any default encryption mechanisms provided by the operating system.<br />
<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=1}}<br />
<br />
'''A Visual Example:'''<br />
<br />
iGoat is a purposefully vulnerable mobile app for the security community to explore these types of vulnerabilities first hand. In the exercise below, we enter our credentials and log in to the fake bank app. Then, we navigate to the file system. Within the applications directory, we can see a database called “credentials.sqlite”. Exploring this database reveals that the application is storing our username and credentials (Jason:pleasedontstoremebro!) in plain text.<br />
<br />
[[Image:Screen%20Shot%202012-12-19%20at%206.34.23%20AM.png]] <br />
[[Image:Screen%20Shot%202012-12-19%20at%206.44.51%20AM.png]] <br />
[[Image:Screen%20Shot%202012-12-19%20at%2010.11.15%20AM.png]]<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=1}}<br />
* [https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet OWASP ][https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet IOS Developer Cheat Sheet]<br />
* [http://source.android.com/tech/security/ Google Androids Developer Security Topics 1]<br />
* [http://developer.android.com/guide/topics/security Google Androids Developer Security Topics 2]<br />
* [https://developer.apple.com/library/mac/ Apple's Introduction to Secure Coding]<br />
* [http://h30499.www3.hp.com/t5/Application-Security-Fortify-on/Exploring-The-OWASP-Mobile-Top-10-M1-Insecure-Data-Storage/ba-p/5904609 Fortify On Demand Blog - Exploring The OWASP Mobile Top 10: Insecure Data Storage]</div>Stephencorhttps://wiki.owasp.org/index.php?title=Mobile_Top_10_2014-M1&diff=183437Mobile Top 10 2014-M12014-10-08T06:57:09Z<p>Stephencor: </p>
<hr />
<div><center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center><br />
{{Top_10_2010:SubsectionColoredTemplate|<center>Weak Server Side Controls</center>||year=2014}}<br />
<br />
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}<br />
{{Top_10_2010:SummaryTableValue-2-Template|Detectability|AVERAGE}}<br />
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}<br />
{{Top_10_2010:SummaryTableHeaderEndTemplate}}<br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat agents include any entity that acts as a source of untrustworthy input to a backend API service, web service, or traditional web server application. Examples of such entities include: a user, malware, or a vulnerable app on the mobile device.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The attack vectors correspond to the same attack vectors available through the traditional OWASP Top Ten.</td><br />
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In order for this vulnerability to be exploited, the organization must expose a web service or API call that is consumed by the mobile app. The exposed service or API call is implemented using insecure coding techniques that produce an OWASP Top Ten vulnerability within the server. Through the mobile interface, an adversary is able to feed malicious inputs or unexpected sequences of events to the vulnerable endpoint. Hence, the adversary realizes the original OWASP Top Ten vulnerability on the server.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The technical impact of this vulnerability corresponds to the technical impact of the associated vulnerability (defined in the OWASP Top Ten) that the adversary is exploiting via the mobile device.<br />
For example, an adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the mobile device. This corresponds to the OWASP Top Ten A3 - XSS Category with a technical impact of moderate.</td><br />
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>The business impact of this vulnerability corresponds to the business impact of the associated vulnerability (defined in the OWASP Top Ten) that the adversary is exploiting via the mobile device.<br />
For example, an adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the mobile device. This corresponds to the OWASP Top Ten A3 - XSS Category's business impacts.</td><br />
{{Top_10_2010:SummaryTableEndTemplate}}<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=2}}<br />
M1 encompasses almost everything that a mobile application can do badly that does not take place on the phone. Which is exactly the argument… should it be listed at all? Don’t we have a Top Ten lists for Web Applications? Don’t we have one for cloud too?<br />
<br />
In fact, we do. If we could be altogether sure that everyone who wanted information on mobile security also stopped by those projects… it would be a perfect world. After two rounds of data collection from some of the world’s top assessment teams, server side issues are so prevalent in mobile applications that we cannot ignore them in the Mobile Top Ten 2014 listing. Experience suggests that several factors have lead to a proliferation of server-side vulnerabilities. These factors include:<br />
<br />
* Rush to market;<br />
* Lack of security knowledge because of the new-ness of the languages;<br />
* Easy access to frameworks that don’t prioritize security;<br />
* Higher than average outsourced development;<br />
* Lower security budgets for mobile applications;<br />
* Assumption that the mobile OS takes full responsibility for security; and <br />
* Weakness due to cross-platform development and compilation.<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=2}}<br />
Secure coding and configuration practices must be used on server-side of the mobile application. For specific vulnerability information, refer to the OWASP Web Top Ten or Cloud Top Ten projects.<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=2}}<br />
<br />
<br />
Below, you can see that there are many risks and vulnerabilities that you must mitigate in order to satisfy M1:<br />
<br />
<br />
<center>[[File:CloudTT_thum.png|border|400px|link=https://www.owasp.org/index.php/Category:OWASP_Cloud_%E2%80%90_10_Project]] [[File:WebTT_thumb.png|border|400px|link=https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project]]</center><br />
<br />
=== The Worst Offenders ===<br />
<br />
Below is a list vulnerability types that OWASP sees most often within mobile applications:<br />
<br />
<br />
;Poor Web Services Hardening<br />
: Logic flaws<br />
:: [https://www.owasp.org/index.php/Testing_for_business_logic_(OWASP-BL-001) Testing for business logic flaws]<br />
:: [https://www.owasp.org/index.php/Business_Logic_Security_Cheat_Sheet Business Logic Security Cheat Sheet]<br />
: Weak Authentication<br />
:: [https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management OWASP Top Ten Broken Authentication Section]<br />
:: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet Authentication Cheat Sheet]<br />
:: [https://www.owasp.org/index.php/Guide_to_Authentication Developers Guide for Authentication]<br />
:: [https://www.owasp.org/index.php/Testing_for_authentication Testing for Authentication]<br />
: Weak or no session management<br />
: Session fixation<br />
: Sensitive data transmitted using GET method<br />
<br />
<br />
; Insecure web server configurations<br />
: Default content<br />
: Administrative interfaces<br />
<br />
<br />
; Injection (SQL, XSS, Command) on both web services and mobile-enabled websites<br />
<br />
; Authentication flaws<br />
<br />
; Session Management flaws<br />
<br />
; Access control vulnerabilities<br />
<br />
; Local and Remote File Includes<br />
<br />
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=2}}<br />
References</div>Stephencor