OWASP - User contributions [en]

Javascript obfuscation

2020-01-08T21:10:19Z

Gtorok: Added page on JavaScript Obfuscation

== What is JavaScript obfuscation and in app protection? ==
An obfuscator converts JavaScript source code into something that is virtually unreadable by humans but remains fully functional. In conjunction with obfuscation, various self-defending techniques can be injected to protect the app. For example:
* Execution can be prevented within a debugger. This may stop easy inspection and probing.
* Execution can be prevented if the app is tampered with in any way. This may hinder probing and theft.
* Execution can be limited to a certain time range. This may be useful for demos.
* Execution can be limited to running from a specified domain. This may prevent someone from easily copying and reusing it.

== What are the difference between minification and obfuscation for JavaScript apps?==
Both transform your JavaScript app, but their goals are entirely different.
The goal of minification is to improve performance by decreasing the size of your code.
A JavaScript minifier will typically remove whitespace, comments, new line characters, etc. Generally, anything that can be removed without compromising functionality is taken out. Some minifiers also change some identifier names as a way to save space. This makes the code harder to read for a casual viewer, but that is a side effect and not the main intent.
The goal of obfuscation and in-app protection is to make the app harder to inspect, probe, alter or misuse.
Obfuscators typically perform standard minification techniques, but might also apply additional renaming techniques that can further reduce the size of the app. If an obfuscator stopped there, it would match or beat a minifier in size reduction. However, many of its other protection and self-defending transforms add code, so overall it may or may not reduce the size of your original app depending on your configuration options. 

== What is different about obfuscating Java or .NET vs. obfuscating JavaScript apps?==
Unlike languages like Java or .NET which compile to some type of intermediate language before being distributed as binary executables, JavaScript apps are generally delivered as source code for execution.
That makes it inherently more difficult to protect them from copying, inspection, theft and tampering. And hackers can easily step through the executing code via a debugger built into their browser. Also, since they have the source, they can easily use tools to statically analyze the code for vulnerabilities.

<big><blockquote>
Java or .NET -> Compiler -> Executable -> Obfuscator & Protector -> Protected Executable
 
JavaScript Source Code -> Obfuscator & Protector -> Protected Source Code
</blockquote></big>

== What criteria should I consider when deciding to obfuscate and protect a JavaScript app? ==
* Does it contain code you don't want competitors to copy or steal?
* Would an attacker want to bypass some of your checks or actively look for vulnerabilities?
* Is there a risk that the code might be modified to serve malware, enable phishing, etc.?
If the answer is “yes” to any of these questions, then you might consider obfuscating and protecting your JavaScript code. It will make it more difficult for a hacker to do these things.
However, obfuscating and protecting your JavaScript will NOT make these things impossible, only much harder. The only way to completely protect JavaScript code is to not run in it in an untrusted environment where potential attackers can access it. But with today’s architectures, it is usually not possible to implement this strategy, because your JavaScript needs to run in web browsers, on mobile devices, on desktops, or even on servers hosted on networks that you don’t control. Obfuscation and other in-app protection techniques provide another layer of security in these situations.
In addition, attackers can use many different paths through your application to do harm to your business or organization.
For a more comprehensive look at these attack vectors see:
* [https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project/ OWASP Top 10 Application Security Risks]


==What are some techniques used by a JavaScript Obfuscator and Protection Tool?==
* Renaming changes the name of identifiers making them much harder for a human to read. The new names can follow different schemes like "a", "b", "c", or unprintable characters. Names may be used multiple times in a scope by using function overloading. Renaming is a basic technique used by almost every obfuscator.
* Control Flow Obfuscationcreates conditional, branching, and iterative constructs that produce valid executable logic, but are much harder for humans to understand.
* String Encryption encodes string literals in the source code, and adds logic to decode them when needed. This removes clues that attackers and tools use to understand the code when performing static analysis.
* Integer and Boolean Transformations transforms integer and Boolean literals into equivalent expressions that are harder to statically analyze and understand.
* Dummy Code Insertion inserts code that does not affect the program’s logic, but makes the code much harder to analyze.
* Debugger Removal removes key information from JavaScript making it harder for hackers to inspect.
* PropertyIndirection changes direct property access to indirect property access making it harder to follow code execution. This also allows property names to be encoded.
* DomainLock binds the code to a domain or subdomain. If the JavaScript is downloaded to the browser from a non-matching domain, it will break.
* DateLock allows the code to only run in a certain date range. If the current date is not in that range the code will fail to execute properly.
* Self-Defending Functions wraps code to observe if a function’s body has been altered in any way. If it has, then the code will fail to execute properly.
* Debugger Detection prevents the code from running when a debugger is active. If the code detects that it is running inside a debugger, it will stop running.

== Further Reading ==
* [https://blog.usejournal.com/javascript-web-application-security-guide-fdade350e373/ JavaScript Web Application Security Guide]
* [https://www.preemptive.com/blog/article/1146-no-beans-about-it-why-you-need-javascript-obfuscation/106-risk-management/ Why you need JavaScript Obfuscation to Manage Risk?]

Bytecode obfuscation

2019-12-03T20:03:49Z

Gtorok: Added Google's R8 tool

==Status==
Completely Updated: 7 March 2018 
Released: 14/1/2008
==Author==
Pierre Parrend

== Principles ==

Java source code is typically compiled into Java bytecode -- the instruction set of the Java virtual machine. The compiled Java bytecode can be easily reversed engineered back into source code by a freely available decompilers.
Bytecode Obfuscation is the process of modifying Java bytecode (executable or library) so that it is much harder to read and understand for a hacker but remains fully functional. Almost all code can be reverse-engineered with enough skill, time and effort. However, for some platforms such as Java, Android, or.NET, free decompilers can easily reverse-engineer source code from an executable or library with no real time or effort.
Automated bytecode obfuscation makes reverse-engineering a program difficult and economically unfeasible. Other advantages could include helping to protect licensing mechanisms and unauthorized access, hiding vulnerabilities and shrinking the size of the executable.

=== How to recover Source Code from Bytecode? ===
There are a number of freely available Java decompilers that can recreate source code from Java bytecode (executables or libraries). Popular decompilers include:
* [https://bytecodeviewer.com Bytecode Viewer] - A Java 8 Jar & Android APK Reverse Engineering Suite (Decompiler, Editor, Debugger & More)
* [http://www.benf.org/other/cfr/ CFR] - Another Java decompiler
* [http://jd.benow.ca/ JDGui] - Yet another fast Java decompiler
* [https://github.com/fesh0r/fernflower Fernflower] - An analytical decompiler for Java

=== How to help prevent Java source code from being Reverse-Engineered? ===
Java bytecode obfuscation consists of multiple complementary techniques that can help create a layered defense against reverse engineering and tampering. Some typical examples of obfuscation techniques include:
* Renaming to alter the name of methods and variables to make the decompiled source much harder for a human to understand.
* Control Flow Obfuscationcreates conditional, branching, and iterative constructs that produce valid executable logic, but yield non-deterministic semantic results when decompiled.
* String Encryption hides strings in the executable and only restores their original value when needed
* Instruction Pattern Transformation converts common instructions to other, less obvious constructs potential confusing decompliers.
* Dummy Code Insertion inserts code that does not affect the program’s logic, but breaks decompilers or makes reverse-engineered code harder to analyze.
* Unused Code and Metadata Removal prunes out debug, non-essential metadata and used code from applications to reduce the information available to an attacker.
* Class file encryption requires the JVM to decrypt the java executable before running confusing decompilers. Unlike some of the other transforms, this one is easy to circumvent by modifing the local JVM to simply write the executable to disk in its unencrypted form. See: [http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html?page=2 Javaworld article]). 

=== What obfuscation tools are available? ===
You can find popular tools for Java bytecode obfuscation below, or simply type 'java obfuscator' in your favorite search engine.
* [https://sourceforge.net/projects/proguard/ ProGuard Java Optimizer] is a very popular open source Java class file shrinker, optimizer, obfuscator, and preverifier.
* [https://www.preemptive.com/products/dasho/overview DashO Android & Java Obfuscator] a Java, Kotlin and Android application hardening and obfuscation tool that provides passive and active protection.
* [http://www.zelix.com/klassmaster/ KlassMaster Heavy Duty Protection], shrinks and obfuscates both code and string constants. It can also translate stack traces back to readable form if you save the obfuscation log.
* [http://sourceforge.net/projects/javaguard/ Javaguard], a simple obfuscator without a lot of documentation.
* [https://discotek.ca/modifly.xhtml Modifly], a feature-rich byte code obfuscator capable of run-time transformations (never run the same byte code twice, yet each run is functionally equivalent).

For Android also see:
* [https://r8-docs.preemptive.com/ Google's R8 code shrinker] Google intends R8 to be a drop-in replacement for ProGuard.

== Using Proguard ==
The following section provides a short tutorial for using [http://proguard.sourceforge.net/ Proguard].
First, download the code under [http://sourceforge.net/project/showfiles.php?group_id=54750 following url] and unzip it.

For this tutorial, we use the [http://www.rzo.free.fr/applis/fr.inria.ares.sfelixutils-0.1.jar fr.inria.ares.sfelixutils-0.1.jar package].

Go to the main directory of Proguard. To launch it, use following script and parameters:

java -jar lib/proguard.jar @config-genericFrame.pro

config-genericFrame.pro is the option file
(do not forget to adapt the libraryjars parameter to your own system) :

-obfuscationdictionary ./examples/dictionaries/compact.txt
-libraryjars /usr/java/j2sdk1.4.2_10/jre/lib/rt.jar
-injars fr.inria.ares.sfelixutils-0.1.jar
-outjar fr.inria.ares.sfelixutils-0.1-obs.jar
-dontshrink
-dontoptimize
-keep public class proguard.ProGuard {
public static void main(java.lang.String[]);
}

Remark that the 'keep' option is mandatory, we use this default class for not keep anything out.

The example dictionary (here compact.txt) is given with the code.

The output is stored in the package 'genericFrameOut.jar'.

You can observe the modifications implied by obfuscation with following commands:

jar xvf genericFrameOut.jar
cd genericFrame/pub/gui/
jad c.class
more c.jad more c.jad

== Links ==
* [https://www.guardsquare.com/en/proguard Proguard]
* [http://sourceforge.net/projects/javaguard/ Javaguard]
* [https://www.preemptive.com/obfuscation Elements of Java Obfuscation]
* [https://en.wikipedia.org/wiki/Obfuscation_(software) Software Obfuscation]
[[Category:Java]]
[[Category:How To]]
[[Category:Control]]

OWASP Reverse Engineering and Code Modification Prevention Project

2019-08-21T16:57:59Z

Gtorok: /* News and Events */

=Overview=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==Project Description==

This project educates security professionals about the risks of reverse engineering and how to ensure that code cannot be reverse engineered or modified. If you are placing sensitive code in an environment in which an attacker can get physical access to that environment (read: mobile, desktops, cloud, particular geographies), you should be concerned with the risks of reverse engineering or unauthorized code modification. This umbrella project will help you understand the risks and how to mitigate them.

==A Brief History of This Problem Space==

Historically, organizations offered their customers web applications that exposed an interface to some necessary business services. The services expose high-value functionality that allows an organization to deliver value to its clients. Attackers had a specific set of threats or goals that they realized by exploiting vulnerabilities that the organization exposed through the application’s presentation layer. Security practitioners address these specific sets of vulnerabilities through the web application or the associated infrastructure security disciplines.

Most often, attackers successfully realized their threats by providing malicious input that they fed into the web application’s presentation layer. Classic attack vectors used by attackers that use this technique include: SQL Injection, Cross-Site (XSS) Scripting, and URL parameter tampering vulnerabilities. Often, security professionals detect the presence of these vulnerabilities through source code analysis or penetration testing. In response to the detection, security professionals recommend to the organization that its Software Engineers should mitigate these vulnerabilities by applying secure coding techniques and adding appropriate data validation security controls to the affected application. Generally, this is sage advice and it works well for traditional web-based applications. In this common scenario, this advice is enforceable because the organization is hosting the web application in a highly controlled (more trustworthy) environment where only the organization’s Software Engineers can modify the application’s underlying code.

In present day, consumers have demanded richer user experiences than what organizations could traditionally offer through web applications they exposed online. In response to these demands, organizations began augmenting the user experience with mobile applications. These applications offer genuinely quicker and richer user experiences than what users would otherwise get through traditional browser-based web applications.

In making the switch to mobile applications, organizations are now deploying more of the presentation layer and business layer of the application on a phone instead of on their own servers. As a result, they lose a lot more control over who gets to see or modify their application’s code. Before the switch, most of the application’s presentation and business layer functionality was hidden within the organization’s trusted server environments. Outside users or attackers did not get much of an opportunity to see executing code in action.

With the recent move towards mobile applications, an attacker can now see, touch, and directly modify a lot of the application’s presentation and business layer code within the attacker’s mobile computing environment. This capability allows the attacker to realize the same traditional business threats as before (with web applications) but in genuinely new and unconventional ways.

==Licensing==

Any documentation or educational material associated with this project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What does this project deliver? ==

Prevent an attacker from reverse engineering your code or making unauthorized changes to that code. The following audiences get something from this project:

* ''Risk Specialists'' - Understand the business and technical risks that an attacker will deploy in order to reverse engineer or modify your code in unsafe environments;

* ''Security Architects'' - Understand the architectural features that should be embedded into code to prevent an attacker from reverse engineering or modifying your code;

* ''Penetration Testers'' - Learn how to conduct binary attacks against mobile apps understand threats that can be realized against various different platforms. You'll have a better understanding of useful attack vectors to verify the strength of reverse engineering prevention or unauthorized code modification;

* ''Software Engineers'' - Learn things that you can do to make reverse engineering as painful as possible for someone that is interested in reverse-engineering your code.

== Sub-projects ==

''RISK'': [[Technical Risks of Reverse Engineering and Unauthorized Code Modification]]

This sub-project helps organizations understand the various technical risks that they are exposed to when they host sensitive code in untrustworthy environments. It is useful to stakeholders that must decide how/if to mitigate these risks.

''ARCHITECTURE'': [[Architectural Principles That Prevent Code Modification or Reverse Engineering]]

This sub-project helps security architects and designers understand the features of their application that should be included to prevent reverse engineering or code modification.

== Related Projects ==

This project is associated with
* [[OWASP_Mobile_Security_Project]]
* [[OWASP_AppSensor_Project]]
* [[OWASP_iMAS_iOS_Mobile_Application_Security_Project]]
* [[Mobile_Jailbreaking_Cheat_Sheet]]

| valign="top" style="padding-left:25px;width:200px;" |

== Project Contributors ==

* Jonathan Carter (Leader)
* Kajihara Masao (Project Contributor)
* Jim DelGrosso (Project Contributor)
* Chris Stahly (Project Contributor)
* Rennie Allen (Project Contributor)

== Presentations ==
* [[Media:OWASP Mobile App Hacking (AppSecUSA 2015) Workshop Feedback.pdf]]
* [[Media:Consequences_of_a_Jailbroken_iDevice.pdf]]
* [[Media:Mobile Risks and Solutions.pdf]]
* [[Media:OWASP Mobile App Hacking (AppSecUSA 2014) Workshop Content.pdf]]
* [[Media:OWASP Mobile App Hacking (AppSecUSA 2014) Feedback.pdf]]

== News and Events ==
* [Sept 2019] - Global AppSec DC 2019
* [May 2015] - AppSecEU Workshop 2015 conducted
* [May 2015] - Oracle Webinar on Project Conducted
* [September 2014] - AppSec USA Workshop 2014 conducted
* [April 2014] - Architectural Principles content finalized and released
* [March 2014] - Technical Risks content translated into Japanese
* [January 2014] - Technical Risks content finalized and released
* [December 2013] - Establishment of project wiki

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=FAQs=

; Is there anything that an organization can really do to prevent someone from modifying their code if the attacker has physical access to the code?
: Absolutely. There are a lot of things that Software Engineers can do to prevent an attacker from understanding or modifying their code.

; Is this really a frequently occurring problem?
: Yes, this is a huge problem that many different business verticals have had to deal with over time. It's just now starting to hit the web and mobile development communities.

= Road Map and Getting Involved =

=Project About=
{{:Projects/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

Application Hardening and Shielding

2018-07-31T17:11:49Z

Gtorok: Added NIST publications to regulations list

Application Hardening and Shielding

== App Hardening and Shielding ==
A set of technologies that typically modify an application’s binary code to make it more resistant to reverse-engineering, tampering, invasive monitoring and intrusion. Enterprises harden their applications to protect their software assets and the data touched by the application.
== Risks ==
For applications that contain unique IP or process sensitive data or functionality, the potential risks of NOT applying some form of hardening and/or shielding may include:
*Intellectual Property theft
*Piracy
*Vulnerability discovery
*Malware-based exploits
*Unauthorized data access and breaches

== Regulations ==
The growing emphasis on application hardening and shielding as a required application security layer is fueling regulatory and statutory changes including (but not limited to)
*2016: Defend Trade Secret Act and EU Directive 943: These coordinated updates to trade secret theft protection are notable in that reverse engineering is explicitly excluded from the definition of misappropriation (theft) – meaning that courts will not consider IP made accessible via reverse-engineering to be treated as a “secret” – and, as such, that IP could not be protected under these laws. This legislation created an entire new set of obfuscation use cases.
*2017: DFARS and PCI Mobile: In each of these two very different control frameworks, Least Privilege risk mitigation controls were updated to require active anti-debug & anti-root/jailbreak controls.
*2017: 2018 PCI PIN Entry and GDPR: Both transactional security and personal privacy standards declare code security and data protection to be inseparable – security by design and by default.
*2018: NIST: National Institute of Standards and Technology publications include increasingly prescriptive obligations for application developers around data security.

== Industry Consensus ==
One hundred percent industry consensus around application protection and security is impossible to achieve. However, OWASP is trying to create quality go-to guidelines. It recently released new protection guidelines around how mobile apps handle, store and protect sensitive information. For example, the
[https://www.owasp.org/images/6/61/MASVS_v0.9.4.pdf OWASP Mobile Application Security Verification Standard] under section V8: Resiliency Against Reverse Engineering Requirements among other things recommends that apps:
* Detect and respond to the presence of a jailbroken device
* Prevent or detect debugging attempts
* Include multiple defense mechanisms
* Leverage obfuscation and encryption

== Conclusion ==
App hardening and shielding along with layered security measures are recognized as a critical component of overall IT compliance. Be familiar with applicable standards and regulations; and implement app development best practices to enhance security for all your apps that process or give access to sensitive data or functionality.
And, perhaps an obvious confirmation, but application hardening is meant to complement, not replace other security controls. See the [https://www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide OWASP Mobile Security Testing Guide] for an comprehensive information on mobile application security.

== Further Reading ==
* [https://www.pcisecuritystandards.org/documents/PCI_Mobile_Payment_Acceptance_Security_Guidelines_for_Developers_v2_0.pdf PCI Mobile Payment Acceptance Security Guidelines for Developers]
* [https://gdpr-info.eu/art-25-gdpr/ GDPR - Data protection by design and by default]
* [https://www.congress.gov/bill/114th-congress/senate-bill/1890/text Defend Trade Secrets Act of 2016]
* [https://www.gartner.com/smarterwithgartner/five-mobile-app-security-techniques-hackers-dont-want-you-to-use/ Five Mobile App Security Techniques Hackers Don’t Want You to Use]
* [https://www.preemptive.com/blog/article/986-technology-trust-issues-when-running-in-untrusted-environments-try-application-shielding/102-mobile-protection Article:Technology Trust Issues When Running in UNTRUSTED Environments? Try Application Shielding]
* [https://dzone.com/articles/what-approach-to-application-hardening-is-right-fo Article:What Approach to Application Hardening is Right For You?]
* [https://www.preemptive.com/blog/article/1046-latest-nist-publications-reinforce-development-obligations-in-securing-data/106-risk-management Article:NIST Publications reinforce the importance of application hardening in securing data]

.NET Obfuscation

2018-07-31T16:59:36Z

Gtorok: Created complementary page for .NET (IL) vs. Java (Bytecode) Obfuscation

== What is .NET? ==
.NET is a free, cross-platform, open source developer platform for building many different types of applications. With .NET, you can use multiple languages, editors, and libraries to build for web, mobile, desktop, gaming, and IoT.

== What are .NET Assemblies? ==
A .NET project generates assemblies (usual executables) that contains Intermediate Language (IL) instructions, managed resources and metadata describing the types, methods, properties, fields and events. The metadata and IL instructions maintain high-level information about your code including its structure and class, field, method, property and parameter names. This makes it possible to understand the assembly structure and the method instructions in order to easily decompile the assembly back to high-level source code.

== Why might I want to obfuscate .NET Assemblies / Executables? ==
An attacker could easily reverse engineer and/or debug a .NET program to understand how it was implemented, which would allow them to easily copy the functionality, or manipulate / steal sensitive information or algorithms. Obfuscating the application before releasing it modifies the executable so that it is difficult to reverse engineer or probe by a hacker. While obfuscation may change metadata or the actual method instructions, it does not alter the logic flow or the output of the program.

==What are some techniques used by an Obfuscator?==
* Renaming to alter the name of methods and variables to make the decompiled source much harder for a human to understand. The new names can follow different schemes like "a", "b", "c", or numbers, characters from non-Latin scripts, unprintable characters or invisible characters. Names may be used multiple times in a scope by using method overloading. Name obfuscation is the most basic technique that is used by every .NET obfuscator solution. Microsoft’s Visual Studio includes a basic [https://docs.microsoft.com/en-us/visualstudio/ide/dotfuscator/ .NET Obfuscator] by default which performs renaming.
* Control Flow Obfuscationcreates conditional, branching, and iterative constructs that produce valid executable logic, but yield non-deterministic semantic results when decompiled.
* String Encryption hides strings in the executable and only restores their original value when needed. Since the string data must be restored automatically at runtime, a hacker could execute the application in a debugger to capture the string values.
* Instruction Pattern Transformation converts common instructions to other, less obvious constructs potential confusing decompliers.
* Dummy Code Insertion inserts code that does not affect the program’s logic, but breaks decompilers or makes reverse-engineered code harder to analyze.
* Unused Code and Metadata Removal prunes out debug, non-essential metadata and used code from applications to reduce the information available to an attacker.

==Attack Detection Technologies==
While technically not obfuscation, App Hardening and Shielding tools typically have the ability to detect and respond to potential attacks on application code including tamper detection, debug detection, and jailbroken device detection making it harder for attackers to steal IP or gain access to sensitive data used by the application.

== Further Reading ==
* [https://www.owasp.org/index.php/Application_Hardening_and_Shielding Application Hardening and Shielding]
* [https://www.owasp.org/index.php/Bytecode_obfuscation Java Bytecode Obfuscation]
* [https://blog.xamarin.com/protecting-xamarin-apps-dotfuscator/ Obfuscating Xamarin Apps]
* [https://github.com/MicrosoftDocs/visualstudio-docs/blob/master/docs/ide/dotfuscator/index.md Microsoft’s Visual Studio & Dotfuscator Docs]

OWASP Application Security FAQ

2018-07-19T17:49:35Z

Gtorok: Added Application Hardening and Shielding explanation and internal OWASP link to misc. section

=Login Issues =

==What are the best practices I should remember while designing the login pages? ==

* From the login page, the user should be sent to a page for authentication. Once authenticated, the user should be sent to the next page. This is explained in the answer to the next question.
* The password should never be sent in clear text (unencrypted) because it can be stolen by sniffing; saving the password in clear text in the database is dangerous too.
* The best way to manage sessions would be to use one session token with two values during authentication. One value before authentication and one after.

==Is it really required to redirect the user to a new page after login? ==

Is it really required to redirect the user to a new page after login?

Yes. Consider the application has a login page that sends the username and password as a POST request to the server. If a user clicks refresh on the second page (the page after login), the same request including the username and password in the POST will be sent again. Now suppose a valid user browses through our application and logs out, but does not close the window. The attackers come along and click the back button of the browser till they reach the second page. They only have to do a refresh and since the username and password are resubmitted and revalidated, the attackers can login as the user. Now let's assume the application has a login page which takes the user to an intermediate page for authentication. Once authenticated, the user is redirected to the second page with a session token. In this case, even if the attackers reach the second page and do a refresh, the username and password will not be resubmitted. This is so because the request that will be submitted is the one for the second page which does not contain the username and password. Therefore, it is always better to redirect the user.

==How can my "Forgot Password" feature be exploited? ==

The Forgot Password feature is implemented in a number of different ways. One common way is to ask the user a hint question for which the user has submitted the answer during registration. These are questions like What is your favorite color? or What is your favorite pastime? If the answer is correct, either the original password is displayed or a temporary password is displayed which can be used to log in. In this method, an attacker trying to steal the password of a user may be able to guess the correct answer of the hint question and even reset the password.

==In "Forgot Password", is it safe to display the old password? ==

If the old password is displayed on the screen, it can be seen by shoulder surfers. So it is a good idea not to display the password and let the user change to a new one. Moreover, displaying the password means it has to be stored in a recoverable form in the database which is not a good practice. If the password is stored as a one way hash in the database, the only way Forgot Password can be implemented is by letting the user reset the old password. So, it is always better to force the users reset their passwords when they forget their passwords. (A one way hash is the result obtained when we pass a string to a one way hash function. The result is such that it is impossible to get back the original value from it. Passwords are best stored as non-recoverable hashes in the database.)

==Is there any risk in emailing the new password to the user's authorized mail id? ==

Emailing the actual password in clear text can be risky as an attacker can obtain it by sniffing. Also the mail containing the password might have a long life time and could be viewed by an attacker while it is lying in the mailbox of the user.

Apart form the above threats, a malicious user can do shoulder-surfing to view the password or login credentials.

==What is the most secure way to design the Forgot Password feature? ==

We should first ask the user to supply some details like personal details or ask a hint question. Then we should send a mail to the users authorized mail id with a link which will take the user to a page for resetting the password. This link should be active for only a short time, and should be SSL- enabled. This way the actual password is never seen. The security benefits of this method are: the password is not sent in the mail; since the link is active for a short time, there is no harm even if the mail remains in the mailbox for a long time.

==How do I protect against automated password guessing attacks? ==

Password guessing with automated tools is a serious problem since there are a number of tools available for this purpose. These tools essentially keep trying out different passwords till one matches. Locking out the account after 5 failed attempts is a good defense against these tools. However, the important point then is how long you lock out the account for. If it is for too long, service to valid users might be denied as the attackers repeatedly lock out your users. If the time is too short say about 1-2 minutes, the tool could start again after the timeout. So the best method would be to insist on human intervention after a few failed attempts. A method used by a number of sites these days is to have the user read and enter a random word that appears in an image on the page. Since this cannot be done by a tool, we can thwart automated password guessing. The following are some tools that guess passwords of web applications: Brutus - http://www.hoobie.net/brutus/ WebCracker http://www.securityfocus.com/tools/706

==How can I protect against keystroke loggers on the client machine? ==

Keystroke loggers on the end users machines can sometimes ruin all our efforts of securely transmitting and storing the passwords. The users themselves may not be aware that a key logger has been installed on their machines and records each key pressed. Since the highest risk is with the password, if we can authenticate the users without having them use the keyboard, or reveal the entire password, we solve the problem. The different ways of doing this are:

* Having a graphical keyboard where the users can enter the characters they want by clicking the mouse on it. This is especially useful for numeric PINs.
* Asking the users to type a part of their password each time and not the whole password. For example you could say "Please enter the 1st, 3rd and 6th letters of your password" and this rule could be a random one each time.
==My site will be used from publicly shared computers. What precautions must I take? ==

If the application will be accessed from publicly shared computers such as libraries, the following may protect its security.

* Avoid caching the site's pages on the system by setting the correct cache control directives.
* Exclude sensitive information from the site's URLs since the history of the client browser will store these.
* Consider protecting user input against external recording via keyboard loggers or video cameras. A graphical keyboard or prompts for a varying part of the password may help.
* Use TLS to prevent sniffing or modifying sensitive data in transit.
* Avoid weak hash algorithms in storing sensitive data by [[Password_Storage_Cheat_Sheet#Impose_infeasible_verification_on_attacker|making it harder to inverse the hash]]. The clear text password in the memory should be reset after computing the hash.

=SQL Injection =

==What is SQL Injection? ==

SQL Injection is a technique by which attackers can execute SQL statements of their choice on the backend database by manipulating the input to the application. Let's understand SQL Injection through the example of a login page in a web application where the database is SQL Server. The user needs to input Username and Password in the text boxes in Login.asp page. Suppose the user enters the following: Username : Obelix and Password : Dogmatix This input is then used to build a query dynamically which would be something like: SELECT * FROM Users WHERE username= 'Obelix' and password='Dogmatix' This query would return to the application a row from the database with the given values. The user is considered authenticated if the database returns one or more rows to the application. Now, suppose an attacker enters the following input in the login page: Username : ' or 1=1-- The query built will look like this: SELECT * FROM Users WHERE username='' or 1=1-- and password='' -- in SQL Server is used to comment out the rest of the line. So, our query is now effectively: SELECT * FROM Users WHERE username='' or 1=1 This query will look in the database for a row where either username is blank or the condition 1=1 is met. Since the latter always evaluates to true, the query will return all rows of the Users table and the user is authenticated. The attacker has been successful in logging into the application without a username and password. You can read more on this at the Securiteam site: http://www.securiteam.com/securityreviews/5DP0N1P76E.html

==Is it just ASP and SQL Server or are all platforms vulnerable? ==

Almost all platforms are vulnerable to SQL Injection. Inadequate checking of user input and the use of dynamic SQL queries are what make an application vulnerable to these attacks. The syntax of the input entered for SQL Injection will depend on the database being used. During our application security audits we have found many applications using other databases to be vulnerable. The above example would work on SQL Server, Oracle and MySQL. This shows that the problem is with the inadequate checking of user input and the use of dynamic SQL and not the underlying database.

==Apart from username and password which variables are candidates for SQL Injection? ==

Any input field that makes up the where clause of a database query is a candidate for SQL Injection, eg. account numbers, and credit card numbers in the case of an online banking application. In addition to form fields, an attacker can use hidden fields and query strings also for injecting commands.

Apart from input fields, URL parameters are also vulnerable to SQL Injection as well as other input based attacks.

==How do we prevent SQL Injection in our applications? ==

It is quite simple to prevent SQL injection while developing the application. You need to check all input coming from the client before building a SQL query. The best method is to remove all unwanted input and accept only expected input. While server side input validation is the most effective method of preventing SQL Injection, the other method of prevention is not using dynamic SQL queries. This can be achieved by using stored procedures or bind variables in databases that support these features. For applications written in Java, CallableStatements and PreparedStatements can be used. For ASP applications, ADO Command Objects can be used. You can check the following article for more on SQL Injection in Oracle: http://www.integrigy.com/info/IntegrigyIntrotoSQLInjectionAttacks.pdf

==I'm using stored procedures for authentication, am I vulnerable? ==

Maybe, but probably no. Using stored procedures can prevent SQL Injection because the user input is no longer used to build the query dynamically. Since a stored procedure is a group of precompiled SQL statements and the procedure accepts input as parameters, a dynamic query is avoided. Although input is put into the precompiled query as is, since the query itself is in a different format, it does not have the effect of changing the query as expected. By using stored procedures we are letting the database handle the execution of the query instead of asking it to execute a query we have built. The exception to this is where the stored procedure takes a string as input and uses this string to build the query without validating it. While this is more difficult to exploit, this scenario still often leads to successful SQL Injection. This article explains how SQL Injection affects stored procedures in more detail: http://palisade.plynt.com/issues/2006Jun/injection-stored-procedures/

==I'm using client side JavaScript code for checking user input. Isn't that enough? ==

No. Although client side checking disallows the attacker to enter malicious data directly into the input fields, that alone is not enough to prevent SQL Injection. Client side scripts only check for input in the browser. But this does not guarantee that the information will remain the same till it reaches the server. To bypass client side JavaScript, the attacker can trap the request in a proxy (eg. WebScarab, [http://www.parosproxy.org Paros]) after it leaves the browser and before it reaches the server and there he can alter input fields. The attacker can also inject commands into the querystring variables which are not checked by the client side scripts, or could disable JavaScript rendering client-side scripting useless.

==Are Java servlets vulnerable to SQL injection? ==

Yes, they are if the user input is not checked properly, and if they build SQL queries dynamically. But Java servlets also have certain features that prevent SQL Injection like CallableStatements and PreparedStatements. Like stored procedures and bind variables, they avoid the need of dynamic SQL statements.

==Can an automated scanner discover SQL Injection? ==

Sometimes yes, sometimes no. Whether a scanner can discover SQL injection or not depends on a variety of factors: the discovery technique used, the response from the application when a malformed SQL snippet is added, and some luck. Specifically, scanners that use Blind SQL Injection are most likely to detect SQL Injection. Scanners that claim hundreds of test cases for SQL Injection are misleading. This entry from the [http://www.plynt.com/resources/learn/tools/do_scanners_catch_sql_injectio_1/ Penetration Testing Learning Center] explains this in detail.

=Variable Manipulation =

==Why can't I trust the information coming from the browser? ==

There are chances that the information is modified before it reaches the server. Attackers browsing the site can manipulate the information in a GET or POST request. There are a number of HTTP/HTTPS proxy tools like [http://www.mavensecurity.com/achilles Achilles], Paros, WebScarab, etc which are capable of intercepting all this information and allow the attacker running the tool to modify it. Also, the information that the user sees or provides on a web page has to travel through the internet before it reaches the server. Although the client and the server may be trusted, we cannot be sure that the information is not modified after it leaves the browser. Attackers can capture the information on the way and manipulate it.

==What information can be manipulated by the attacker? ==

Manipulating the variables in the URL is simple. But attackers can also manipulate almost all information going from the client to the server like form fields, hidden fields, content-length, session-id and http methods.

==How do attackers manipulate the information? What tools do they use? ==

For manipulating any information, including form fields, hidden variables and cookies, attackers use tools known as HTTP/HTTPS proxy tools. Once the browser's proxy settings are configured to go through the HTTP/HTTPS proxy, the tool can see all information flowing between the client and the server; it even allows the attacker to modify any part of the request before sending it. Some such tools are: WebScarab can be downloaded from the OWASP site. Odysseus can be found at http://www.bindshell.net/tools/odysseus Paros can be downloaded from http://www.parosproxy.org

==I'm using SSL. Can attackers still modify information? ==

Although SSL provides a lot of security, SSL alone is not enough to prevent variable manipulation attacks. SSL was supposed to prevent against Man in the Middle attacks but it is vulnerable to it. To successfully carry out the MITM attack, first the attacker has to divert the victim's requests to his machine i.e. redirecting the packets meant for the server to himself. He can do this by ARP poisoning / DNS Cache poisoning. Once he is able to redirect, he can see all the requests the victim is trying to make. Now when the victim tries to establish an SSL connection with a legitimate server, he gets connected to the attacker. The attacker, during the SSL Handshaking, provides a fake certificate to the victim, which the victim accepts even though the browser warns him. Thus, the victim establishes an SSL connection with the attacker instead of the server. The attacker establishes a different SSL connection with that legitimate server, which the victim was trying to connect. Now all data flow between the victim and the server will be routed through the attacker and the attacker can see all data the victim (as well as the server) sends. This is because the victim will encrypt all data with the attacker's public key, which the attacker can decrypt with his private key. The attacker can then manipulate all data that is passing through his machine.

==Is there some way to prevent these proxy tools from editing the data? ==

The main threat these proxy tools pose is editing the information sent from the client to the server. One way to prevent it is to sign the message sent from the client with a Java Applet downloaded onto the client machine. Since the applet we developed will be the one validating the certificate and not the browser, a proxy tool will not be able to get in between the client and the server with a fake certificate. The applet will reject the fake certificate. The public key of this certificate can then be used to digitally sign each message sent between the client and the server. An attacker would then have to replace the embedded certificate in the applet with a fake certificate to succeed - that raises the barrier for the attacker.

=Browser Cache =

==How can the browser cache be used in attacks? ==

The browser has a capability to temporarily store some of the pages browsed. These cached files are stored in a folder, like the Temporary Internet Files folder in the case of Internet Explorer. When we ask for these pages again, the browser displays them from its cache. This is much faster than downloading the page from the server. Let's consider the particular scenario where a user has logged in to an application with username and password. The user browses the different pages which contain sensitive information. Let's suppose a page with the user's credit card information gets cached in the browser and the user logs out of the application. Now suppose the attackers access the same machine and searches through the Temporary Internet Files, they will get the credit card details. The attackers do not need to know the username and password of the user to steal the information.

==How do I ensure that sensitive pages are not cached on the user's browser? ==

The response header sent from the server has some cache control directives that can be set from your code. These directives control the caching of content on any cache. The directives to be set are Cache-Control : no-cache, no-store and Expires: 0. But since legacy HTTP 1.0 servers do not support the Cache-Control headers, universally, Pragma: no-cache header should be used, too.

==What's the difference between the cache-control directives: no-cache, and no-store? ==

The no-cache directive in a response indicates that the response must not be used to serve a subsequent request i.e. the cache must not display a response that has this directive set in the header but must let the server serve the request. The no-cache directive can include some field names; in which case the response can be shown from the cache except for the field names specified which should be served from the server. The no-store directive applies to the entire message and indicates that the cache must not store any part of the response or any request that asked for it.

==Am I totally safe with these directives? ==

No. But generally, use both Cache-Control: no-cache, no-store and Pragma: no-cache, in addition to Expires: 0 (or a sufficiently backdated GMT date such as the UNIX epoch). Non-html content types like pdf, word documents, excel spreadsheets, etc often get cached even when the above cache control directives are set (although this varies by version and additional use of must-revalidate, pre-check=0, post-check=0, max-age=0, and s-maxage=0 in practice can sometimes result at least in file deletion upon browser closure in some cases due to browser quirks and HTTP implementations). Also, 'Autocomplete' feature allows a browser to cache whatever the user types in an input field of a form. To check this, the form tag or the individual input tags should include 'Autocomplete="Off" ' attribute. However, it should be noted that this attribute is non-standard (although it is supported by the major browsers) so it will break XHTML validation.

==Where can I learn more about caching? ==

Some useful links that talk about caching are - Caching Tutorial for Web Authors and Webmasters by Mark Nottingham at http://www.mnot.net/cache_docs/ and HTTP RFC (sec14.9.1) at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

=Cross Site Scripting =

==What is Cross Site Scripting? ==

Cross Site scripting (XSS) is a type of attack that can be carried out to steal sensitive information belonging to the users of a web site. This relies on the server reflecting back user input without checking for embedded javascript. This can be used to steal cookies and session IDs. Let's see how it works. We would all have come across the following situation sometime - we type a URL in the browser, say www.abcd.com/mypage.asp, and receive an error page that says "Sorry www.abcd.com/mypage.asp does not exist" or a page with a similar message. In other words, pages that display the user input back on the browser. Pages like this could be exploited using XSS. Instead of a normal input, think what will happen if the input contains a script in it. While reflecting back the input, instead of rendering it as normal HTML output, the browser treats it as a script and executes it. This script could contain some malicious code. The attackers can send a link that contains a script as part of the URL to a user. When the user clicks it, the script gets executed on the user's browser. This script may have been written to collect important information about the user and send it to the attacker. Kevin Spett's paper Cross Site Scripting, Are your web applications vulnerable? is a good source of information on this topic and is available at http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf The Cross Site Scripting FAQ at CGI Security is another good place to learn more on XSS.

==What information can an attacker steal using XSS? ==

The attackers can steal the session ID of a valid user using XSS. The session ID is very valuable because it is the secret token that the user presents after login as proof of identity until logout. If the session ID is stored in a cookie, the attackers can write a script which will run on the user's browser, query the value in the cookie and send it to the attackers. The attackers can then use the valid session ID to browse the site without logging in. The script could also collect other information from the page, including the entire contents of the page.

==Apart from mailing links of error pages, are there other methods of exploiting XSS? ==

Yes, there are other methods. Let's take the example of a bulletin board application that has a page where data entered by one user can be viewed by other users. The attackers enter a script into this page. When a valid user tries to view the page, the script gets executed on the user's browser. It will send the user's information to the attackers.

==How can I prevent XSS? ==

XSS can be prevented while coding the application. You should be validating all input and output to and from the application and escape all special characters that may be used in a script. If the code replaces the special characters by the following before displaying the output, XSS can be prevented to some extent.

{| class="wikitable"
! style="text-align:center;"| Special Character
! Escape Sequence
|-
|<||&lt;
|-
|>||&gt;
|-
|(||&#40;
|-
|)||&#41;
|-
|*||&#42;
|-
|&||&amp;
|}

Gunter Ollmann has written an excellent paper on the use of special characters in XSS attacks. For instance, the above technique of escaping special characters cannot protect against a script injected like "javascript:self.location.href = 'www.evil.org' " as this script does not use any of the special characters.

==Can XSS be prevented without modifying the source code? ==

There is a method that requires minimal coding as compared to performing input, output validation to prevent the stealing of cookies by XSS. Internet Explorer 6 has an attribute called HTTP Only that can be set for cookies. Using this attribute makes sure that the cookie can not be accessed by any scripts. More details are available at the MSDN site on httpcookies at http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/httponly_cookies.asp Mozilla also has plans to implement a similar feature. Researchers have found a method to beat this. It is known as Cross Site Tracing.

==What is Cross Site Tracing (XST)? How can it be prevented? ==

Attackers are able to bypass the HTTP Only attribute to steal cookie information by Cross Site tracing (XST). TRACE is a HTTP method that can be sent to the server. The server sends back anything included in the TRACE request back to the browser. In a site that uses cookies, the cookie information is sent to the server in each request. If we send a TRACE request in a URL of such a site, the server will send back all cookie information to the browser. Now imagine a situation similar to the one described in XSS but the site in this case is using the HTTP Only cookies. The attackers make a valid user click on a link that contains a script that calls the TRACE method. When the user clicks on the link the TRACE request as well as all the cookie information is sent to the server. The server then sends back the cookie information back to the script in the browser. Suppose that the malicious script also contains code to send this information to the attackers. The attackers have succeeded again in stealing the cookies although HTTP Only Cookies were used. To summarize, HTTP Only cookies prevent the JavaScript from directly accessing the cookies but the attacker was able to retrieve it through an indirect method. XST can be prevented by disabling the TRACE method on the web server. This paper by Jeremiah Grossman discusses XST in greater detail http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf

=Web Server Fingerprinting =

==How do attackers identify which web server I'm using? ==

Identifying the application running on a remote web server is known as fingerprinting the server. The simplest way to do this is to send a request to the server and see the banner sent in the response. Banners will generally have the server name and the version number in it. We can address this problem by either configuring the server not to display the banner at all or by changing it to make the server look like something else.

==How can I fake the banners or rewrite the headers from my web server? ==

There are a number of tools that help in faking the banners. URLScan is a tool that can change the banner of an IIS web server. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/URLScan.asp mod_security has a feature for changing the identity of the Apache web server. It can be found at http://www.modsecurity.org/ Servermask for faking banners of IIS, can be found at http://www.servermask.com/

==Once I fake the banners, can my web server still be fingerprinted? ==

Yes. Unfortunately there are tools that fingerprint the web server without relying on the banners. Different web servers may implement features not specified in HTTP RFCs differently. Suppose we make a database of these special requests and the responses of each web server. We can now send these requests to the web server we want to fingerprint and compare the responses with the database. This is the technique used by tools like Fire & Water. This tool can be found at http://www.ntobjectives.com/products/firewater/ There is a paper by Saumil Shah that discusses the tool httprint at http://net-square.com/httprint/httprint_paper.html httprint can be found at http://net-square.com/httprint/

==A friend told me it's safer to run my web server on a non-standard port. Is that right? ==

A web server generally needs to be accessed by a lot of people on the internet. Since it normally runs on port 80 and all browsers are configured to access port 80 of the web server, users are able to browse the site. If we change the port, the users will have to specify the port in addition to the domain name. But this is a good idea for an intranet application where all users know where to connect. It is more secure since the web server will not be targeted by automated attacks like worms that scan port 80 and other standard ports.

==Should I really be concerned that my web server can be fingerprinted? ==

Well, there are two schools of thought here. According to the first school, yes you should take precaution against fingerprinting as correctly identiying the web server maybe the first step in a more dangerous attack. Once attackers have found out that the web server is say IIS 5, they will search for known vulnerabilities for IIS 5. If the web server is not patched for all known vulnerabilities or the attackers find one for which a patch has not been released yet, there is nothing to stop them from attacking it. Also automated tools and worms can be fooled by changing the version information. Some determined and focused attackers might go to additional lengths to identify the server but the hurdles that the attackers have to overcome have increased when it's more difficult to fingerprint the web server name and version. Jeremiah Grossman pointed out the other school of thought. Evasive measures are futile as any scanner targeting a web site, will normally not care what the web server is. The scanner will run ALL its tests no matter if they apply to the system or not. This is a typical shotgun approach. A bad guy targeting the site might be hampered by not knowing the exact version, but if he's determined he would still try out all related exploits and try to break in.

=Testing =

==I want to chain my proxy tool with a proxy server; are there tools that let me do that? ==

Yes, there are several tools that allow proxy chaining. Some of these are: WebScarab - http://www.owasp.org/development/webscarab Exodus - http://home.intekom.com/rdawes/exodus.html Odysseus - http://www.wastelands.gen.nz/odysseus/index.php

==Can't web application testing be automated? Are there any tools for that? ==

There are tools that scan applications for security flaws. But these tools can only look for a limited number of vulnerabilities, and do not find all the problems in the application. Moreover, a lot of attacks require understanding of the business context of the application to decide on the variables to manipulate in a particular request, which a tool is incapable of doing. A presentation by Jeremiah Grossman of White Hat Security which talks about the [http://www.blackhat.com/presentations/bh-federal-03/bh-fed-03-grossman-up.pdf limitations of automated scanning].

This piece explains [http://www.plynt.com/resources/learn/tools/what_cant_a_scanner_find_1/ what a scanner can't find].

In our tests using a slightly modified WebGoat the best Black-box scanning tool found less than 20% of the issues ! Some tools for automated scanning are: SpikeProxy, open source and freely available at http://www.immunitysec.com/spikeproxy.html WebInspect, can be found at http://www.spidynamics.com/productline/WE_over.html

==Where can I try out my testing skills? Is there a sample application I can practice with? ==

OWASP provides a sample application that can be used for this purpose called . As the site says, the WebGoat project's goal is to teach web security in an interactive teaching environment. There are lessons on most of the common vulnerabilities. Another interesting site is Hackingzone which has a game on SQL Injection at http://www.hackingzone.org/sql/index.php

==Are there source code scanning tools for .NET languages, Java, PHP etc that predict vulnerabilities in the source code? ==

Rough Auditing Tool for Security (RATS) is a tool that scans the source code for security flaws in C, C++, Python, Perl and PHP programs. It can be found at http://code.google.com/p/rough-auditing-tool-for-security/downloads/list FX Cop was created by the Microsoft Team at the GotDotNet community site to check for the .NET Frameowork guidelines which include security. Prexis is a commercial source code and run-time analyzer. Flawfinder is a static source code analyzer. Compaq ESC is a run-time analyzer for Java. Parasoft AEP is a commercial source code analyzer for Java. Fortify SCA from Fortify Software is another source code analyzer that supports mixed language analysis of C, C++, C#, ASP.NET, Java, JSP, PL/SQL, VB.NET, XML, etc. Secure Coding plugins are also available. Similar source code analyzers are Klocwork K7 for C, C++ and Java; Coverity Prevent for detecting security violations and defects in code; Ounce Solutions for C, C++, C#, ASP.NET, Java and JSP. We would like to know about more tools for scanning source code. If you know about any, please inform us and we'll add to this FAQ

==Can non-HTTP protocols also be intercepted and played with like this? ==

Yes, Interactive TCP Replay is a tool that acts as a proxy for non-HTTP applications and also allows modifying the traffic. It allows editing of the messages in a hex editor. ITR also logs all the messages passing between the client and the server. It can use different types of character encoding like ASCII or EBCDIC for editing and logging. More information on this can be found at http://www.webcohort.com/web_application_security/research/tools.html

=Cryptography/SSL =

==What is SSL? ==

Secure Socket Layer (SSL) gives us assurance of two things. Firstly when a client connects to a web server, the client can be sure that it is talking to the right server by checking the certificate the server sends it. Secondly, SSL assures you of the confidentiality of the data, as the client and the server exchange encrypted messages that cannot be understood by anybody else. This is how SSL works: When the client requests for a SSL page, the server sends a certificate that it has obtained from a trusted certificate authority. This certificate contains the public key of the server. After satisfying itself that the certificate is correct and the server is a genuine one, the client generates one random number, the session key. This key is encrypted by the public key of the server and sent across. The server decrypts the message with its private key. Now both sides have a session key known only to the two of them. All communication to and fro is encrypted and decrypted with the session key. An interesting link on SSL is http://www.rsasecurity.com/standards/ssl/basics.html

==Should I use 40-bit or 128-bit SSL? ==

There are 2 strengths in SSL - 40-bit and 128-bit. These refer to the length of the secret key used for encrypting the session. This key is generated for every SSL session and is used to encrypt the rest of the session. The longer the key the more difficult it is to break the encrypted data. So, 128-bit encryption is much more secure than 40-bit. Most browsers today support 128-bit encryption. There are a few countries which have browsers with only 40-bit support. In case you are using 40-bit SSL, you may need to take further precautions to protect sensitive data. Salted hash for transmitting passwords is a good technique. This ensures that the password can not be stolen even if the SSL key is broken.

==Is 40-bit SSL really unsafe? ==

40-bit SSL is not really unsafe. It's just that it is computationally feasible to break the key used in 40-bit but not the key used in 128-bit. Even though 40-bit can be broken, it takes a fairly large number of computers to break it. Nobody would even attempt to do that for a credit card number or the like. But there are claims of breaking the 40-bit RC4 key in a few hours. So depending on the data your application deals with, you can decide on the SSL strength. Using 128-bit is definitely safer.

With home computers gtting faster day by day, a dedicated, expensive and very fast computer can break 40-bit encryption in few minutes (ideally testing a million keys per second). On the other hand, 128-bit encryotion will have about 339,000,000,000,000,000,000,000,000,000,000,000 (Couple of Trillions or 2^128) possible key combinations and it will take around 1000 Years to break 128-bit encryptions with the help of a cluster of very fast computers.

==What all are encrypted when I use SSL? Is the page request also encrypted? ==

After the initial SSL negotiation is done and the connection is on HTTPS, everything is encrypted including the page request. So any data sent in the query string will also be encrypted.

==Which cryptographic algorithms do SSL use? ==

SSL supports a number of cryptographic algorithms. During the initial "handshaking" phase, it uses the RSA public key algorithm. For encrypting the data with the session key the following algorithms are used - RC2, RC4, IDEA, DES, triple-DES and MD5 message digest algorithm.

==I want to use SSL. Where do I begin? ==

There are several Certificate Authorities that you can buy a SSL certificate from. Whichever CA you choose, the basic procedure will be as follows -

* Create key pair for the server
* Create the Certificate Signing Request. This will require you to provide certain details like location and fully qualified domain name of the server.
* Submit the CSR to the CA along with documentary proof of identity.
* Install the certificate sent by the CA
The first two steps are done from the web server. All servers have these features. While installing the certificate issued by the CA, you will have to specify which web pages are to be on SSL.

A good starting point for working on POC in a Windows development environment could be: "HOW TO: Secure XML Web Services with Secure Socket Layer in Windows 2000" - http://support.microsoft.com/default.aspx?scid=kb;en-us;q307267&sd=tech

=Cookies and Session Management =

==Are there any risks in using persistent vs non-persistent cookies? ==

Persistent cookies are data that a web site places on the user's hard drive (or equivalent) for maintaining information over more than one browser session. This data will stay in the user's system and can be accessed by the site the next time the user browses the site. Non-persistent cookies on the other hand are those that are used only in the browser session that creates it. They stay only in the memory of the machine and are not persisted on the hard disk. The security risk with persistent cookies is that they are generally stored in a text file on the client and an attacker with access to the victim's machine can steal this information.

==Can another web site steal the cookies that my site places on a user's machine? ==

No, it is not possible for a website to access another site's cookies. Cookies have a domain attribute associated with them. Only a request coming from the domain specified in the attribute can access the cookie. This attribute can have only one value.

==Which is the best way to transmit session ids- in cookies, or URL or a hidden variable? ==

Transmitting session IDs in the URL can lead to several risks. Shoulder surfers can see the session ID; if the URL gets cached on the client system, the session ID will also be stored; the session ID will get stored in the referrer logs of other sites. Hidden variables are not always practical as every request might not be a POST. Cookies are the safest method as cookies do not get cached, are not visible in the W3C or referrer logs, and most users anyway accept cookies.

==What are these secure cookies? ==

A cookie can be marked as "secure" which ensures the cookie is used only over SSL sessions. If "secure" is not specified, the cookie will be sent unencrypted over non-SSL channels. Sensitive cookies like session tokens should be marked as secure if all pages in the web site requiring session tokens are SSL-enabled. One thing to keep in mind here is that images are generally not downloaded over SSL and they usually don't require a session token to be presented. By setting the session cookie to be secure, we ensure that the browser does not send the cookie while downloading the image over the non-SSL connection.<>

==If I use a session ID that is a function of the client's IP address, will session hijacking be prevented? ==

An attacker can hijack another user's session by stealing the session token. Methods have been suggested to prevent the session from being hijacked even if the session token is stolen. For instance, using a session token that is a function of the user's IP address. In this approach, even if the attacker stole the token, he would need the same IP address as the user to successfully hijack a session. However, session hijacking can still be possible. Suppose the attacker is on the same LAN as the user and uses the same Proxy IP as the user to access the web site. The attacker can still steal the session if he is able to sniff the session token. It may also be not possible to implement this if the IP of the client changes during a session, making the session invalid if the token is tied to the initial IP address. This may happen if the client is coming from behind a bank of proxy servers.

==How about encrypting the session id cookies instead of using SSL? ==

Encrypting just the session ID over a non-SSL connection will not serve any purpose. Since the session ID will be encrypted once and the same value will be sent back and forth each time, an attacker can use the encrypted value to hijack the session.

==What is the concept of using a page id, in addition to the session id? ==

A Session ID or token has the lifetime of a session and is tied to the logged in user. A page ID or token has a lifetime of a page and is tied to a page that is served. It is a unique token given when a page is downloaded and is presented by the user when accessing the next page. The server expects a particular value for the user to access the next page. Only if the token submitted matches what the server is expecting is the next page served. An application can use this to ensure that a user accesses pages only in the sequence determined by the application. The user cannot paste a deep URL in the browser and skip pages just because he has a session token, as the page token would not be authorized to access the deeper URL directly. Good Read: [http://palisade.plynt.com/issues/2005Aug/page-tokens/ Secure your sessions with Page Tokens]

=Logging and Audit Trails =

==What are these W3C logs? ==

W3C is a logging format used for Web server log files. W3C logs record access details of each request: the timestamp, source IP, page requested, the method used, http protocol version, browser type, the referrer page, the response code etc. Note that these are access logs, and so a separate record is maintained for each request. When a page with multiple gif files is downloaded, it would be recorded as multiple entries in the W3C log; so, W3C logs tend to be voluminous.

==Do I need to have logging in my application even if I've W3C logs? ==

Yes, it's important that your application maintains "application level" logs even when W3C logging is used. As W3C logs contain records for every http request, it is difficult (and, at times impossible) to extract a higher level meaning from these logs. For instance, the W3C logs are cumbersome to identify a specific session of user and the activities that the user performed. It's better that the application keeps a trail of important activities, rather than decode it from W3C logs.

==What should I log from within my application? ==

Keep an audit trail of activity that you might want to review while troubleshooting or conducting forensic analysis. Please note that it is inadvisable to keep sensitive business information itself in these logs, as administrators have access to these logs for troubleshooting. Activities commonly kept track of are:

* Login and logout of users
* Critical transactions (eg. fund transfer across accounts)
* Failed login attempts
* Account lockouts
* Violation of policies
The data that is logged for each of these activities usually include:

* User ID
* Time stamp
* Source IP
* Error codes, if any
* Priority
==Should I encrypt my logs? Isn't that a performance hit? ==

Encryption is required when information has to be protected from being read by unauthorized users. Yes, encryption does take a performance hit, so if your logs do not contain sensitive information you might want to forego encryption. However, we strongly urge that you protect your logs from being tampered by using digital signatures. Digital signatures are less processor intensive than encryption and ensure that your logs are not tampered.

==Can I trust the IP address of a user I see in my audit logs? Could a user be spoofing/impersonating their IP address? ==

A bad guy who wants to hide his actual IP address might use a service like anonymizer, or use open HTTP relays. [HTTP open relays are improperly configured web servers on the web that are used as a HTTP proxy to connect to other sites.] In such cases, the IP address you see in your log files will be those of these services or the open relay that is being used. So, the IP address you see in your log files might not always be trustworthy.

=Miscellaneous =

==What are Buffer Overflows? ==

Buffer overflow vulnerability affects the web applications that require user input. The application stores the input in a buffer which is of a fixed size, as defined by the programmer. When the input that is sent to the application is more than the buffer capacity and the buffers are left unchecked, buffer overflow occurs. The severity depends on the user input. If a malicious code executes as a result of the overflow, it can even compromise the whole system.
To learn more, please read the OWASP article on [http://www.owasp.org/index.php/Buffer_Overflow buffer overflows.]

==What are application firewalls? How good are they really? ==

Application firewalls analyze the requests at the application level. These firewalls are used for specific applications like a web server or a database server. The web application firewalls protect the web server from HTTP based attacks. They monitor the requests for attacks that involve SQL Injection, XSS, URL encoding etcetera. However, application layer firewalls cannot protect against attacks that require an understanding of the business context - this includes most attacks that rely on variable manipulation. Some application firewalls are: Netcontinuum's NC-1000 Kavado Inc.'s InterDo Teros Inc.'s Teros-100 APS

==What is all this about "referrer logs", and sensitive URLs? ==

The HTTP header contains a field known as Referrer. For visiting a web page we may either:

* Type its URL directly into the address bar of the browser
* Click a link on some other page that brings us there
* Be redirected there by some page.
In the first case, the referrer field will be empty but in the other two cases it will contain the URL of the previous page. The URL of the first page will get stored in the web server access logs of the second page when the user reaches the second page from the first page. Now suppose, the two pages belong to different sites and the first URL contains sensitive information like a user's session ID. If the second site belongs to attackers, they can obtain this information by just going through the logs. Information in the URLs will get stored in the referrer logs as well as the history of the browser. Therefore, we should be careful not to have any sensitive information in the URL.

==What is Application Hardening and Shielding? ==

Application Hardening and Shielding is a set of technologies that typically modify an application’s binary code to make it more resistant to reverse-engineering, tampering, invasive monitoring and intrusion. Enterprises harden their applications to protect their software assets and the data touched by the application.

To learn more, please read the OWASP article on [http://www.owasp.org/index.php/Application_Hardening_and_Shielding App Hardening and Shielding].

==I want to use the most secure language; which language do you recommend? ==

Any language can be used since secure programming practices are what make applications safe. Most security techniques can be implemented in any language. Our advice would be to use any language you are comfortable with. But some languages like Java have additional features like bind variables that aid security; you could use those additional features if you decide to program in that language.

==What are the good books to learn secure programming practices? ==

The OWASP Guide to Building Secure Web Application and Web Services is a good guide for web application developers. You can download it from http://www.owasp.org/documentation/guide Writing Secure Code by Michael Howard and David LeBlanc has a chapter on Securing Web-Based Services. More information on this book can be found at: http://www.microsoft.com/mspress/books/toc/5612.asp Secure Programming for Linux and Unix HOWTO by David Wheeler talks about writing secure applications including web applications; it also specifies guidance for a number of languages. The book can be found at: http://www.dwheeler.com/secure-programs

Another good book on application security, which also covers some web service specific topics: 19 Deadly Sins of Software Security, by: Michael Howard, David LeBlanc and John Viega (http://books.mcgraw-hill.com/getbook.php?isbn=0072260858).

==Are there any training programs on secure programming that I can attend? ==

Microsoft offers training programs on Developing Security-Enhanced Web Applications and Developing and Deploying Secure Microsoft .NET Framework Application. More information can be found at http://www.microsoft.com/traincert/syllabi/2300AFinal.asp and http://www.microsoft.com/traincert/syllabi/2350BFinal.asp Foundstone offers secure coding training through Global Knowledge Aspect Security offers a similar course.

OWASP_FAQ_Ver3.doc

PCI DSS

2018-06-21T14:00:51Z

Gtorok: Rewrote to make current with latest PCI security guidelines

PCI DSS - Mobile Security Recommendations
== PCI Mobile Payment Acceptance Security Guidelines ==
The 2017 PCI Mobile Payment Acceptance Security Guidelines states, “Bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors.”
== Section 4.3 Prevent Escalation of Privileges ==
Controls should exist to prevent the escalation of privileges on the device (e.g., root or group privileges). Bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors. Therefore, the device should be monitored for activities that defeat operating system security controls—e.g., jailbreaking or rooting—and, when detected, the device should be quarantined by a solution that removes it from the network, removes the payment-acceptance application from the device, or disables the payment application. Offline jailbreak and root detection and auto quarantine are key since some attackers may attempt to put the device in an offline state to further circumvent detection. Hardening of the application is a method to that may help prevent escalation of privileges in a mobile device. Controls should include, but are not limited to:
*Providing the capability for the device to produce an alarm or warning if there is an attempt to root or jailbreak the device;
*Providing the capability within the payment-acceptance solution for identifying authorized objects and designing controls to limit access to only those objects
== Links ==
*[https://www.pcisecuritystandards.org/documents/PCI_Mobile_Payment_Acceptance_Security_Guidelines_for_Developers_v2_0.pdf PCI Mobile Payment Acceptance Security Guidelines for Developers • September 2017]
* [https://www.preemptive.com/blog/article/980-an-app-hardening-use-case-filling-the-pci-prescription-for-preventing-privilege-escalation-in-mobile-apps/106-risk-management Blog on Preventing Privilege Escalation in Mobile Payment Apps (PCI Mobile Payment Acceptance Security Guidelines Section 4.3)]
* [http://www.PCISecurityStandards.org PCISecurityStandards.org Website]

OWASP .NET Recommended Resources

2018-05-11T12:39:18Z

Gtorok: Added Resources

{| align="right" class="wikitable"
|-
! OWASP .NET Quick Reference
|-
|
*[[OWASP Code Review Project]] 
*[[OWASP Testing Guide]] 
|-
|}
==OWASP .NET Recommended Resources==

This is a canonical list of outside resources for .NET developers seeking security information.

===Blogs & People===

[http://securitybuddha.com/ Mark Curphrey's Blog]

[http://blogs.msdn.com/michael_howard/default.aspx Michael Howard's Blog]

[http://blogs.msdn.com/jmeier/archive/tags/Security/default.aspx J.D. Meier's Blog]

[http://www.leastprivilege.com Dominick Baier's Blog]

[http://blogs.msdn.com/shawnfa/default.aspx Shawn Farkas' Blog]

[http://blogs.msdn.com/ace_team/ Microsoft's ACE Team]

[http://www.troyhunt.com/ Troy Hunt's Blog]

[https://www.preemptive.com/blog App Protection Blog]

===Advisories, Articles & Projects===

[http://msdn.microsoft.com/en-us/library/ee658105.aspx Security and Operational Guidance for .NET Applications]

[http://msdn2.microsoft.com/en-us/library/yedba920.aspx ASP.NET Security Architecture]

[http://msdn.microsoft.com/en-us/library/ms998404.aspx patterns & practices Security Engineering Index]

[http://msdn.microsoft.com/en-us/library/ms998408.aspx patterns & practices Security Guidance for Applications Index]

[http://msdn.microsoft.com/en-us/library/ms954725.aspx patterns & practices Security Guidance for .NET Framework 2.0]

[http://msdn.microsoft.com/en-us/library/Ee817643(pandp.10).aspx Authentication in ASP.NET: .NET Security Guidance]

[http://msdn2.microsoft.com/en-us/library/ms998404.aspx Security Engineering]

[http://www.developer.com/design/article.php/3607471 Solutions to SOA Security]

[http://en.wikipedia.org/wiki/WS-%2A Web Service Specifications]

[http://wcfsecurityguide.codeplex.com/ Security Guidance for Windows Communication Foundation]

[http://www.microsoft.com/technet/security/advisory/954462.mspx Microsoft Security Advisory (954462) (SQL Injection Advisory)]

[https://www.microsoft.com/en-us/sdl Security Development Lifecycle]

===Online References, Training===

[http://msdn2.microsoft.com/en-us/practices/default.aspx Patterns and Practices]

[http://msdn.microsoft.com/en-us/security/default.aspx MSDN Security Developer Center]

[http://blogs.technet.com/feliciano_intini/pages/microsoft-blogs-and-web-resources-about-security.aspx Microsoft Security Resources]

[http://pluralsight.com/training/Courses#security Pluralsight Security Course Catalog]

[http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-1.html OWASP Top 10 for .NET developers - Troy Hunt]

[http://www.teammentor.net/teamMentor TeamMentor]

[https://docs.microsoft.com/en-us/dotnet/standard/security/ Security in the .NET Framework]

===Books and Publications===

[http://www.microsoft.com/mspress/books/5957.aspx Writing Secure Code], Michael Howard and David LeBlanc

[http://www.microsoft.com/downloads/details.aspx?familyid=2412c443-27f6-4aac-9883-f55ba5b01814&displaylang=en&Hash=4fZb2FzZ7%2bmaj0VqoUbFZzzw0WW5%2bxWjK3XBVit5eX%2b%2bB90vmLtZlAstlNg9cRu6Pg%2b50DNCMhGT6ADei7DgFg%3d%3d Microsoft Security Development Lifecycle 3.2]

[http://msdn.microsoft.com/en-us/library/aa302415.aspx Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication], J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy

[http://msdn.microsoft.com/en-us/library/ms994921.aspx Improving Web Application Security: Threats and Countermeasures], J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan

[http://msdn.microsoft.com/en-gb/security/aa473878.aspx Developer Highway Code], Microsoft Corp, United Kingdom

[http://securitydriven.net/ Security Driven .NET], Stan Drapkin

===Tools===

[http://blogs.msdn.com/b/sdl/archive/2014/04/15/introducing-microsoft-threat-modeling-tool-2014.aspx Microsoft Threat Modeling Tool 2014]

[http://msdn.microsoft.com/en-us/security/aa973814.aspx Anti-Cross Site Scripting]

[http://learn.iis.net/page.aspx/473/using-urlscan URLScan]

[http://support.microsoft.com/kb/954476 Microsoft Source Code Analyzer]

[http://support.microsoft.com/kb/954476 MS Source Code Analyser for SQL Injection]

[https://docs.microsoft.com/en-us/visualstudio/ide/dotfuscator/ Visual Studio .NET Obfuscator]

Mobile Top 10 2016-M2-Insecure Data Storage

2018-05-02T17:06:59Z

Gtorok: Added threat posed to an app's data running on a rooted or jailbroken device.

{{Mobile_Top_10_2016:TopTemplate
|usenext=Mobile2016NextLink
|next=M3-{{Mobile_Top_10_2016:ByTheNumbers
|3
|year=2016
|language=en}}
|useprev=Mobile2016PrevLink
|prev=M1-{{Mobile_Top_10_2016:ByTheNumbers
|1
|year=2016
|language=en}}
|year=2016
|language=en
}}

{{Mobile_Top_10_2016:SummaryTableHeaderBeginTemplate|year=2016|language=en}}
{{Mobile_Top_10:SummaryTableTemplate|exploitability=1|prevalence=2|detectability=2|impact=1|year=2016|language=en}}
{{Mobile_Top_10_2016:SummaryTableHeaderEndTemplate|year=2016}}
<td {{Template:Mobile Top 10 2016:SummaryTableRowStyleTemplate|year=2016}}>Threats agents include the following: an adversary that has attained a lost/stolen mobile device; malware or another repackaged app acting on the adversary's behalf that executes on the mobile device.

</td>
<td {{Template:Mobile Top 10 2016:SummaryTableRowStyleTemplate|year=2016}}>In the event that an adversary physically attains the mobile device, the adversary hooks 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>
<td colspan=2 {{Template:Mobile Top 10 2016:SummaryTableRowStyleTemplate|year=2016}}>Insecure data storage vulnerabilities occur 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. Usage of poor encryption libraries is to be avoided. 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>
<td {{Template:Mobile Top 10 2016:SummaryTableRowStyleTemplate|year=2016}}>This can result in data loss, in the best case for one user, and in the worst case for many users. It may also result in the following technical impacts: extraction of the app's sensitive information via mobile malware, modified apps or forensic tools.

The nature of the business impact is highly dependent upon the nature of the information stolen. Insecure data may result in the following business impacts:

* Identity theft;
* Privacy violation;
* Fraud;
* Reputation damage;
* External policy violation (PCI); or
* Material loss.

</td>
<td {{Template:Mobile Top 10 2016:SummaryTableRowStyleTemplate|year=2016}}>Insecure data storage vulnerabilities typically lead to the following business risks for the organization that owns the risk app:

* Identity Theft
* Fraud
* Reputation Damage
* External Policy Violation (PCI); or
* Material Loss.

</td>

{{Mobile_Top_10:SubsectionTableBeginTemplate|type=main}} {{Mobile_Top_10_2016:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2016:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=2|year=2016|language=en}}
This category insecure data storage and unintended data leakage. Data stored insecurely includes, but is not limited to, the following:

* SQL databases;
* Log files;
* XML data stores ou manifest files;
* Binary data stores;
* Cookie stores;
* SD card;
* Cloud synced.

Unintended data leakage includes, but is not limited to, vulnerabilities from:

* The OS;
* Frameworks;
* Compiler environment;
* New hardware.
* Rooted or Jailbroken devices

This is obviously without a developer's knowledge. In mobile development specifically, this is most seen in undocumented, or under-documented, internal processes such as:

* The way the OS caches data, images, key-presses, logging, and buffers;
* The way the development framework caches data, images, key-presses, logging, and buffers;
* The way or amount of data ad, analytic, social, or enablement frameworks cache data, images, key-presses, logging, and buffers.

{{Mobile_Top_10_2016:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2016:StyleTemplate}}|subsection=howPrevent|position=right|risk=2|year=2016|language=en}}
It is important to threat model your mobile app, OS, platforms and frameworks to understand the information assets the app processes and how the APIs handle those assets. It is crucial to see how they handle the following types of features :

* URL caching (both request and response);
* Keyboard press caching;
* Copy/Paste buffer caching;
* Application backgrounding;
* Intermediate data
* Logging;
* HTML5 data storage;
* Browser cookie objects;
* Analytics data sent to 3rd parties.

{{Mobile_Top_10_2016:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2016:StyleTemplate}}|subsection=example|position=left|risk=2|year=2016|language=en}}
=== A Visual Example ===

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.

[[Image:Screen%20Shot%202012-12-19%20at%206.34.23%20AM.png]]
[[Image:Screen%20Shot%202012-12-19%20at%206.44.51%20AM.png]]
[[Image:Screen%20Shot%202012-12-19%20at%2010.11.15%20AM.png]]

{{Mobile_Top_10_2016:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2016:StyleTemplate}}|subsection=references|position=right|risk=2|year=2016|language=en}}
{{Mobile_Top_10_2016:SubSubsectionOWASPReferencesTemplate}}
* [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]
{{Mobile_Top_10_2016:SubSubsectionExternalReferencesTemplate}}
* [http://source.android.com/tech/security/ Google Androids Developer Security Topics 1]
* [http://developer.android.com/training/articles/security-tips.html Google Androids Developer Security Topics 2]
* [https://developer.apple.com/library/mac/ Apple's Introduction to Secure Coding]
* [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]

Detect integrity violation incidents (code modification prevention)

2018-03-28T18:59:26Z

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

{{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]]].

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.
Consider how reverse engineering and debugging application attacks can cross data, operational, and IP risk boundaries:
<table style="width:100%">
<tr>
<th>Attack</th>
<th>Resulting Risk</th>
</tr>
<tr>
<td>Circumventing encryption used during data transmission or storage exposes otherwise secured data</td>
<td>Unauthorized data access leads to data loss, loss of revenue, privacy breaches, regulatory non-compliance, and trade secret theft</td>
</tr>
<tr>
<td>Insert and modify data within your application</td>
<td>Altering application to circumvent controls and voiding authorization and access controls to gain access to restricted information or gain additional access for free</td>
</tr>
<tr>
<td>View critical function code, the values of dynamic keys and how sensitive information is saved to your file systems and databases</td>
<td>Loss of highly sensitive data such as: digital keys, certificates, credentials, and proprietary algorithms</td>
</tr>
<tr>
<td>Modify and release a copycat or malware infected version of your application</td>
<td>A redistributed version of your application performs illicit actions that cause reputational damage and exposure</td>
</tr>
</table>
 
[[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. See 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 for more information.

= 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.
As part of a layered protection strategy, companies should have mechanisms in place that add vulnerability masking, anti-debug and anti-tamper functionality directly into an application to protect, detect, and respond to attacks on the application's integrity.

= Examples =
For example, a Checksum control is responsible for detecting code changes between compile-time and runtime of the application.
 As another example, an anti-debug control is important not only because it is a hacker's tool of choice, but because it can be used to insert and modify data within your application.[[[#ReferenceItem5|5]]]

= 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.”''
[5] PreEmptive and Deloitte Review: [https://www.preemptive.com/solutions/application-integrity-protection Application Integrity Protection],
:''“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...”''

Detect integrity violation incidents (code modification prevention)

2018-03-27T19:26:40Z

Gtorok: Added another example and reference

{{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.
As part of a layered protection strategy, companies should have mechanisms in place that add vulnerability masking, anti-debug and anti-tamper functionality directly into an application to protect, detect, and respond to attacks on the application's integrity.

= Examples =
For example, a Checksum control is responsible for detecting code changes between compile-time and runtime of the application.
 As another example, an anti-debug control is important not only because it is a hacker's tool of choice, but because it can be used to insert and modify data within your application.[[[#ReferenceItem5|5]]]

= 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.”''
[5] PreEmptive and Deloitte Review: [https://www.preemptive.com/solutions/application-integrity-protection Application Integrity Protection],
:''“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...”''

Application Hardening and Shielding

2018-03-21T19:43:31Z

Gtorok: Combined definitions for app hardening and app sheilding

Application Hardening and Shielding

== App Hardening and Shielding ==
A set of technologies that typically modify an application’s binary code to make it more resistant to reverse-engineering, tampering, invasive monitoring and intrusion. Enterprises harden their applications to protect their software assets and the data touched by the application.
== Risks ==
For applications that contain unique IP or process sensitive data or functionality, the potential risks of NOT applying some form of hardening and/or shielding may include:
*Intellectual Property theft
*Piracy
*Vulnerability discovery
*Malware-based exploits
*Unauthorized data access and breaches
== Regulations ==
The growing emphasis on application hardening and shielding as a required application security layer is fueling regulatory and statutory changes including (but not limited to)
*2016: Defend Trade Secret Act and EU Directive 943: These coordinated updates to trade secret theft protection are notable in that reverse engineering is explicitly excluded from the definition of misappropriation (theft) – meaning that courts will not consider IP made accessible via reverse-engineering to be treated as a “secret” – and, as such, that IP could not be protected under these laws. This legislation created an entire new set of obfuscation use cases.
*2017: DFARS and PCI Mobile: In each of these two very different control frameworks, Least Privilege risk mitigation controls were updated to require active anti-debug & anti-root/jailbreak controls.
*2017: 2018 PCI PIN Entry and GDPR: Both transactional security and personal privacy standards declare code security and data protection to be inseparable – security by design and by default.
== Industry Consensus ==
One hundred percent industry consensus around application protection and security is impossible to achieve. However, OWASP is trying to create quality go-to guidelines. It recently released new protection guidelines around how mobile apps handle, store and protect sensitive information. For example, the
[https://www.owasp.org/images/6/61/MASVS_v0.9.4.pdf OWASP Mobile Application Security Verification Standard] under section V8: Resiliency Against Reverse Engineering Requirements among other things recommends that apps:
* Detect and respond to the presence of a jailbroken device
* Prevent or detect debugging attempts
* Include multiple defense mechanisms
* Leverage obfuscation and encryption
== Conclusion ==
App hardening and shielding along with layered security measures are recognized as a critical component of overall IT compliance. Be familiar with applicable standards and regulations; and implement app development best practices to enhance security for all your apps that process or give access to sensitive data or functionality.
And, perhaps an obvious confirmation, but application hardening is meant to complement, not replace other security controls. See the [https://www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide OWASP Mobile Security Testing Guide] for an comprehensive information on mobile application security.
== Further Reading ==
* [https://www.pcisecuritystandards.org/documents/PCI_Mobile_Payment_Acceptance_Security_Guidelines_for_Developers_v2_0.pdf PCI Mobile Payment Acceptance Security Guidelines for Developers]
* [https://gdpr-info.eu/art-25-gdpr/ GDPR - Data protection by design and by default]
* [https://www.congress.gov/bill/114th-congress/senate-bill/1890/text Defend Trade Secrets Act of 2016]
* [https://www.gartner.com/smarterwithgartner/five-mobile-app-security-techniques-hackers-dont-want-you-to-use/ Five Mobile App Security Techniques Hackers Don’t Want You to Use]
* [https://dzone.com/articles/what-approach-to-application-hardening-is-right-fo Article:What Approach to Application Hardening is Right For You?]
* [https://www.preemptive.com/blog/article/986-technology-trust-issues-when-running-in-untrusted-environments-try-application-shielding/102-mobile-protection Article:Technology Trust Issues When Running in UNTRUSTED Environments? Try Application Shielding]

Application Hardening and Shielding

2018-03-15T15:03:03Z

Gtorok: Added an article on App Hardening and App Shielding

Application Hardening and Shielding
== Application Hardening ==
Application hardening: a means of reducing risks stemming from reverse-engineering, tampering, and invasive monitoring.
== Application Shielding ==
Application shielding: a means to help prevent, detect and/or respond to potential or actual application-level intrusions.
== Risks ==
For applications that process or give access to sensitive data or functionality, the potential risks of NOT applying some form of hardening and/or shielding may include:
*Intellectual Property theft
*Piracy
*Vulnerability discovery
*Malware-based exploits
*Unauthorized data access and breaches.
== Regulations ==
The growing emphasis on application hardening and shielding as a required application security layer is fueling regulatory and statutory changes including (but not limited to)
*2016: Defend Trade Secret Act and EU Directive 943: These coordinated updates to trade secret theft protection are notable in that reverse engineering is explicitly excluded from the definition of misappropriation (theft) – meaning that courts will not consider IP made accessible via reverse-engineering to be treated as a “secret” – and, as such, that IP could not be protected under these laws. This legislation created an entire new set of obfuscation use cases.
*2017: DFARS and PCI Mobile: In each of these two very different control frameworks, Least Privilege risk mitigation controls were updated to require active anti-debug & anti-root/jailbreak controls.
*2017: 2018 PCI PIN Entry and GDPR: Both transactional security and personal privacy standards declare code security and data protection to be inseparable – security by design and by default.
== Industry Consensus ==
One hundred percent industry consensus around application protection and security is impossible to achieve. However, OWASP is trying to create quality go-to guidelines. It recently released new protection guidelines around how mobile apps handle, store and protect sensitive information. For example, the
[https://www.owasp.org/images/6/61/MASVS_v0.9.4.pdf OWASP Mobile Application Security Verification Standard] under section V8: Resiliency Against Reverse Engineering Requirements among other things recommends that apps:
* Detect and respond to the presence of a jailbroken device
* Prevent or detect debugging attempts
* Include multiple defense mechanisms
* Leverage obfuscation and encryption
== Conclusion ==
Application hardening along with layered security measures are recognized as a critical component of overall IT compliance. Be familiar with applicable standards and regulations; and implement app development best practices to enhance security for all your apps that process or give access to sensitive data or functionality.
And, perhaps an obvious confirmation, but application hardening is meant to complement, not replace other security controls. See the [https://www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide OWASP Mobile Security Testing Guide] for an comprehensive information on mobile application security.
== Further Reading ==
* [https://www.pcisecuritystandards.org/documents/PCI_Mobile_Payment_Acceptance_Security_Guidelines_for_Developers_v2_0.pdf PCI Mobile Payment Acceptance Security Guidelines for Developers]
* [https://gdpr-info.eu/art-25-gdpr/ GDPR - Data protection by design and by default]
* [https://www.congress.gov/bill/114th-congress/senate-bill/1890/text Defend Trade Secrets Act of 2016]
* [https://www.gartner.com/smarterwithgartner/five-mobile-app-security-techniques-hackers-dont-want-you-to-use/ Five Mobile App Security Techniques Hackers Don’t Want You to Use]
* [https://dzone.com/articles/what-approach-to-application-hardening-is-right-fo Article:What Approach to Application Hardening is Right For You?]
* [https://www.preemptive.com/blog/article/986-technology-trust-issues-when-running-in-untrusted-environments-try-application-shielding/102-mobile-protection Article:Technology Trust Issues When Running in UNTRUSTED Environments? Try Application Shielding]

Application Hardening and Shielding

2018-03-08T21:44:55Z

Gtorok: Initial creation

Bytecode obfuscation

2018-03-08T14:06:18Z

Gtorok: Removed "pls_review" tag because the page was completely re-written.

==Status==
Completely Updated: 7 March 2018 
Released: 14/1/2008
==Author==
Pierre Parrend

== Principles ==

Java source code is typically compiled into Java bytecode -- the instruction set of the Java virtual machine. The compiled Java bytecode can be easily reversed engineered back into source code by a freely available decompilers.
Bytecode Obfuscation is the process of modifying Java bytecode (executable or library) so that it is much harder to read and understand for a hacker but remains fully functional. Almost all code can be reverse-engineered with enough skill, time and effort. However, for some platforms such as Java, Android, or.NET, free decompilers can easily reverse-engineer source code from an executable or library with no real time or effort.
Automated bytecode obfuscation makes reverse-engineering a program difficult and economically unfeasible. Other advantages could include helping to protect licensing mechanisms and unauthorized access, hiding vulnerabilities and shrinking the size of the executable.

=== How to recover Source Code from Bytecode? ===
There are a number of freely available Java decompilers that can recreate source code from Java bytecode (executables or libraries). Popular decompilers include:
* [https://bytecodeviewer.com Bytecode Viewer] - A Java 8 Jar & Android APK Reverse Engineering Suite (Decompiler, Editor, Debugger & More)
* [http://www.benf.org/other/cfr/ CFR] - Another Java decompiler
* [http://jd.benow.ca/ JDGui] - Yet another fast Java decompiler
* [https://github.com/fesh0r/fernflower Fernflower] - An analytical decompiler for Java

=== How to help prevent Java source code from being Reverse-Engineered? ===
Java bytecode obfuscation consists of multiple complementary techniques that can help create a layered defense against reverse engineering and tampering. Some typical examples of obfuscation techniques include:
* Renaming to alter the name of methods and variables to make the decompiled source much harder for a human to understand.
* Control Flow Obfuscationcreates conditional, branching, and iterative constructs that produce valid executable logic, but yield non-deterministic semantic results when decompiled.
* String Encryption hides strings in the executable and only restores their original value when needed
* Instruction Pattern Transformation converts common instructions to other, less obvious constructs potential confusing decompliers.
* Dummy Code Insertion inserts code that does not affect the program’s logic, but breaks decompilers or makes reverse-engineered code harder to analyze.
* Unused Code and Metadata Removal prunes out debug, non-essential metadata and used code from applications to reduce the information available to an attacker.
* Class file encryption requires the JVM to decrypt the java executable before running confusing decompilers. Unlike some of the other transforms, this one is easy to circumvent by modifing the local JVM to simply write the executable to disk in its unencrypted form. See: [http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html?page=2 Javaworld article]). 

=== What obfuscation tools are available? ===
You can find popular tools for Java bytecode obfuscation below, or simply type 'java obfuscator' in your favorite search engine.
* [https://sourceforge.net/projects/proguard/ ProGuard Java Optimizer] is a very popular open source Java class file shrinker, optimizer, obfuscator, and preverifier.
* [https://www.preemptive.com/products/dasho/overview DashO Android & Java Obfuscator] a Java, Kotlin and Android application hardening and obfuscation tool that provides passive and active protection.
* [http://www.zelix.com/klassmaster/ KlassMaster Heavy Duty Protection], shrinks and obfuscates both code and string constants. It can also translate stack traces back to readable form if you save the obfuscation log.
* [http://sourceforge.net/projects/javaguard/ Javaguard], a simple obfuscator without a lot of documentation.

== Using Proguard ==
The following section provides a short tutorial for using [http://proguard.sourceforge.net/ Proguard].
First, download the code under [http://sourceforge.net/project/showfiles.php?group_id=54750 following url ] and unzip it.

For this tutorial, we use the [http://www.rzo.free.fr/applis/fr.inria.ares.sfelixutils-0.1.jar fr.inria.ares.sfelixutils-0.1.jar package].

Go to the main directory of Proguard. To launch it, use following script and parameters:

java -jar lib/proguard.jar @config-genericFrame.pro

config-genericFrame.pro is the option file
(do not forget to adapt the libraryjars parameter to your own system) :

-obfuscationdictionary ./examples/dictionaries/compact.txt
-libraryjars /usr/java/j2sdk1.4.2_10/jre/lib/rt.jar
-injars fr.inria.ares.sfelixutils-0.1.jar
-outjar fr.inria.ares.sfelixutils-0.1-obs.jar
-dontshrink
-dontoptimize
-keep public class proguard.ProGuard {
public static void main(java.lang.String[]);
}

Remark that the 'keep' option is mandatory, we use this default class for not keep anything out.

The example dictionary (here compact.txt) is given with the code.

The output is stored in the package 'genericFrameOut.jar'.

You can observe the modifications implied by obfuscation with following commands:

jar xvf genericFrameOut.jar
cd genericFrame/pub/gui/
jad c.class
more c.jad more c.jad

== Links ==
* [https://www.guardsquare.com/en/proguard Proguard]
* [http://sourceforge.net/projects/javaguard/ Javaguard]
* [https://www.preemptive.com/obfuscation Elements of Java Obfuscation]
* [https://en.wikipedia.org/wiki/Obfuscation_(software) Software Obfuscation]
[[Category:Java]]
[[Category:How To]]
[[Category:Control]]

Bytecode obfuscation

2018-03-07T20:38:48Z

Gtorok: Major rewrite - removed broken links and un-maintained tools. Updated description and added current decompilers and obfuscators.

{{taggedDocument
| type=pls_review
}}

==Status==
Released: 14/1/2008 
Updated: 7/3/2018
==Author==
Pierre Parrend

== Principles ==

Java source code is typically compiled into Java bytecode -- the instruction set of the Java virtual machine. The compiled Java bytecode can be easily reversed engineered back into source code by a freely available decompilers.
Bytecode Obfuscation is the process of modifying Java bytecode (executable or library) so that it is much harder to read and understand for a hacker but remains fully functional. Almost all code can be reverse-engineered with enough skill, time and effort. However, for some platforms such as Java, Android, or.NET, free decompilers can easily reverse-engineer source code from an executable or library with no real time or effort.
Automated bytecode obfuscation makes reverse-engineering a program difficult and economically unfeasible. Other advantages could include helping to protect licensing mechanisms and unauthorized access, hiding vulnerabilities and shrinking the size of the executable.

=== How to recover Source Code from Bytecode? ===
There are a number of freely available Java decompilers that can recreate source code from Java bytecode (executables or libraries). Popular decompilers include:
* [https://bytecodeviewer.com Bytecode Viewer] - A Java 8 Jar & Android APK Reverse Engineering Suite (Decompiler, Editor, Debugger & More)
* [http://www.benf.org/other/cfr/ CFR] - Another Java decompiler
* [http://jd.benow.ca/ JDGui] - Yet another fast Java decompiler
* [https://github.com/fesh0r/fernflower Fernflower] - An analytical decompiler for Java

=== How to help prevent Java source code from being Reverse-Engineered? ===
Java bytecode obfuscation consists of multiple complementary techniques that can help create a layered defense against reverse engineering and tampering. Some typical examples of obfuscation techniques include:
* Renaming to alter the name of methods and variables to make the decompiled source much harder for a human to understand.
* Control Flow Obfuscationcreates conditional, branching, and iterative constructs that produce valid executable logic, but yield non-deterministic semantic results when decompiled.
* String Encryption hides strings in the executable and only restores their original value when needed
* Instruction Pattern Transformation converts common instructions to other, less obvious constructs potential confusing decompliers.
* Dummy Code Insertion inserts code that does not affect the program’s logic, but breaks decompilers or makes reverse-engineered code harder to analyze.
* Unused Code and Metadata Removal prunes out debug, non-essential metadata and used code from applications to reduce the information available to an attacker.
* Class file encryption requires the JVM to decrypt the java executable before running confusing decompilers. Unlike some of the other transforms, this one is easy to circumvent by modifing the local JVM to simply write the executable to disk in its unencrypted form. See: [http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html?page=2 Javaworld article]). 

=== What obfuscation tools are available? ===
You can find popular tools for Java bytecode obfuscation below, or simply type 'java obfuscator' in your favorite search engine.
* [https://sourceforge.net/projects/proguard/ ProGuard Java Optimizer] is a very popular open source Java class file shrinker, optimizer, obfuscator, and preverifier.
* [https://www.preemptive.com/products/dasho/overview DashO Android & Java Obfuscator] a Java, Kotlin and Android application hardening and obfuscation tool that provides passive and active protection.
* [http://www.zelix.com/klassmaster/ KlassMaster Heavy Duty Protection], shrinks and obfuscates both code and string constants. It can also translate stack traces back to readable form if you save the obfuscation log.
* [http://sourceforge.net/projects/javaguard/ Javaguard], a simple obfuscator without a lot of documentation.

== Using Proguard ==
The following section provides a short tutorial for using [http://proguard.sourceforge.net/ Proguard].
First, download the code under [http://sourceforge.net/project/showfiles.php?group_id=54750 following url ] and unzip it.

For this tutorial, we use the [http://www.rzo.free.fr/applis/fr.inria.ares.sfelixutils-0.1.jar fr.inria.ares.sfelixutils-0.1.jar package].

Go to the main directory of Proguard. To launch it, use following script and parameters:

java -jar lib/proguard.jar @config-genericFrame.pro

config-genericFrame.pro is the option file
(do not forget to adapt the libraryjars parameter to your own system) :

-obfuscationdictionary ./examples/dictionaries/compact.txt
-libraryjars /usr/java/j2sdk1.4.2_10/jre/lib/rt.jar
-injars fr.inria.ares.sfelixutils-0.1.jar
-outjar fr.inria.ares.sfelixutils-0.1-obs.jar
-dontshrink
-dontoptimize
-keep public class proguard.ProGuard {
public static void main(java.lang.String[]);
}

Remark that the 'keep' option is mandatory, we use this default class for not keep anything out.

The example dictionary (here compact.txt) is given with the code.

The output is stored in the package 'genericFrameOut.jar'.

You can observe the modifications implied by obfuscation with following commands:

jar xvf genericFrameOut.jar
cd genericFrame/pub/gui/
jad c.class
more c.jad more c.jad

== Links ==
* [https://www.guardsquare.com/en/proguard Proguard]
* [http://sourceforge.net/projects/javaguard/ Javaguard]
* [https://www.preemptive.com/obfuscation Elements of Java Obfuscation]
* [https://en.wikipedia.org/wiki/Obfuscation_(software) Software Obfuscation]
[[Category:Java]]
[[Category:How To]]
[[Category:Control]]