Detect integrity violation incidents (code modification prevention) - Revision history

Gtorok: Added more information and a table to the context section

2018-03-28T18:59:26Z

Added more information and a table to the context section

Gtorok: Added another example and reference

2018-03-27T19:26:40Z

Added another example and reference

Jonathan Carter: Created page with "{{Template:Principle}} Category:OWASP Reverse Engineering and Code Modification Prevention Project Category:Principle NOTOC
= Context = Mobile app developers ..."

2014-04-09T23:10:54Z

Created page with "{{Template:Principle}} Category:OWASP Reverse Engineering and Code Modification Prevention Project Category:Principle __NOTOC__ = Context = Mobile app developers ..."

New page

{{Template:Principle}}
[[Category:OWASP Reverse Engineering and Code Modification Prevention Project]]
[[Category:Principle]]
__NOTOC__
 
= Context =
Mobile app developers must take into account a whole host of new risks that relate to hosting code in an uncontrolled environment. If you are hosting code in an untrustworthy environment, you are susceptible to the risk that an adversary will reverse engineer and modify your code via binary attacks [[[#ReferenceItem1|1]]] [[[#ReferenceItem2|2]]] [[[#ReferenceItem3|3]]] [[[#ReferenceItem4|4]]].

[[File:MainProjectIcon.png|30px|link=https://www.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project]] This content is part of a much bigger set of principles defined within the [https://www.owasp.org/index.php/Architectural_Principles_That_Prevent_Code_Modification_or_Reverse_Engineering Architectural Principles That Prevent Code Modification or Reverse Engineering] project.

= Description =
Detecting integrity violation is important because otherwise the attacker has unlimited time to perfect an integrity attack. An integrity violation is defined as an insertion of code into the application.

= Examples =
For example, a Checksum control is responsible for detecting code changes between compile-time and runtime of the application.

= External References =
[1] Arxan Research: [https://www.arxan.com/assets/1/7/State_of_Security_in_the_App_Economy_Report_Vol._2.pdf State of Security in the App Economy, Volume 2], November 2013:
:''“Adversaries have hacked 78 percent of the top 100 paid Android and iOS apps in 2013.”''
[2] HP Research: [http://www8.hp.com/us/en/hp-news/press-release.html?id=1528865#.UuwZFPZvDi5 HP Research Reveals Nine out of 10 Mobile Applications Vulnerable to Attack], 18 November 2013:
:''"86 percent of applications tested lacked binary hardening, leaving applications vulnerable to information disclosure, buffer overflows and poor performance. To ensure security throughout the life cycle of the application, it is essential to build in the best security practices from conception."''
[3] North Carolina State University: [http://www.csc.ncsu.edu/faculty/jiang/pubs/OAKLAND12.pdf Dissecting Android Malware: Characterization and Evolution], 7 September 2011:
:''“Our results show that 86.0% of them (Android Malware) repackage legitimate apps to include malicious payloads; 36.7% contain platform-level exploits to escalate privilege; 93.0% exhibit the bot-like capability.”''
[4] InfoSecurity Magazine: [http://www.infosecurity-magazine.com/view/36376/two-thirds-of-personal-banking-apps-found-full-of-vulnerabilities/ Two Thirds of Personal Banking Apps Found Full of Vulnerabilities], January 3 2014:
:''“But one of his more worrying findings came from disassembling the apps themselves ... what he found was hardcoded development credentials within the code. An attacker could gain access to the development infrastructure of the bank and infest the application with malware causing a massive infection for all of the application’s users.”''

@@ Line 7: / Line 7: @@
 Mobile app developers must take into account a whole host of new risks that relate to hosting code in an uncontrolled environment. If you are hosting code in an untrustworthy environment, you are susceptible to the risk that an adversary will reverse engineer and modify your code via binary attacks <sup>&#91;[[#ReferenceItem1|1]]&#93;</sup> <sup>&#91;[[#ReferenceItem2|2]]&#93;</sup> <sup>&#91;[[#ReferenceItem3|3]]&#93;</sup> <sup>&#91;[[#ReferenceItem4|4]]&#93;</sup>.
-[[File:MainProjectIcon.png|30px|link=https://www.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project]] This content is part of a much bigger set of principles defined within the [https://www.owasp.org/index.php/Architectural_Principles_That_Prevent_Code_Modification_or_Reverse_Engineering Architectural Principles That Prevent Code Modification or Reverse Engineering] project.
+Whether a hacker is trying to pirate your app, steal your data, or alter the behavior of a critical piece of infrastructure software as part of a larger crime – inspecting and/or modifying an application can play an essential role. As part of a layered protection strategy, companies should have mechanisms in place that add anti-decompile, anti-debug, anti-tamper and anti-root controls directly into an application to protect, detect, and respond to attacks on the application's integrity.
 = Description =

@@ Line 11: / Line 11: @@
 = Description =
 Detecting integrity violation is important because otherwise the attacker has unlimited time to perfect an integrity attack. An integrity violation is defined as an insertion of code into the application.
 = Examples =
 For example, a Checksum control is responsible for detecting code changes between compile-time and runtime of the application.
 = External References =
@@ Line 24: / Line 27: @@
 <span id="ReferenceItem4">[4] InfoSecurity Magazine: [http://www.infosecurity-magazine.com/view/36376/two-thirds-of-personal-banking-apps-found-full-of-vulnerabilities/ Two Thirds of Personal Banking Apps Found Full of Vulnerabilities], January 3 2014:
 :''“But one of his more worrying findings came from disassembling the apps themselves ... what he found was hardcoded development credentials within the code. An attacker could gain access to the development infrastructure of the bank and infest the application with malware causing a massive infection for all of the application’s users.”''</span>

Detect integrity violation incidents (code modification prevention) - Revision history

Gtorok: Added more information and a table to the context section

Gtorok: Added another example and reference

Jonathan Carter: Created page with "{{Template:Principle}} Category:OWASP Reverse Engineering and Code Modification Prevention Project Category:Principle __NOTOC__ = Context = Mobile app developers ..."

Jonathan Carter: Created page with "{{Template:Principle}} Category:OWASP Reverse Engineering and Code Modification Prevention Project Category:Principle NOTOC
= Context = Mobile app developers ..."