java secure coding practices

37
The OWASP Foundation http://www.owasp.org Escape \’Attacks!\’ India, Kerala 2015 Rajesh P Board Member, OWASP Kerala Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify the document under the terms of the OWASP License All trademarks, service marks, trade names, product names and logos appearing on the slides are the property of their respective owners Secure Coding Practice Series Parse what you code

Upload: owaspkerala

Post on 16-Jul-2015

104 views

Category:

Engineering


8 download

TRANSCRIPT

Page 1: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

Escape \’Attacks!\’

India, Kerala

2015Rajesh PBoard Member, OWASP Kerala

Copyright © The OWASP FoundationPermission is granted to copy, distribute and/or modify the document under the terms of the OWASP License

All trademarks, service marks, trade names, product names and logos appearing on the slides are the property of their respective owners

Secure Coding Practice Series

Parse what you code

Page 2: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

2

Page 3: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Developer approaches application based on what it is intended to do

• Attacker’s approach is based on what application can be made to do

• Any action not specifically denied is considered allowed

3

Fundamental difference

Page 4: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Minimize Attack Surface Area• Secure Defaults• Principle of Least Privilege• Principle of Defense in Depth• Fail Securely• External Systems are Insecure• Separation of Duties• Do not trust Security through Obscurity• Simplicity• Fix Security Issues Correctly

4

Security Principles

Page 5: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Price related hidden fields, CSS visibility –perform server side validation

• Cross Site Request Forgery (CSRF)• Sensitive Information Disclosure via Client-

Side Storage and Comments• Hardcoded domain in HTML• HTML5: Form validation turned off• Password Submission using GET method

5

HTML

Page 6: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Selects, radio buttons, and checkboxes

Wrong Approach<input type="radio" name="acctNo" value="455712341234">Gold Card<input type="radio" name="acctNo" value="455712341235">Platinum Card

String acctNo = getParameter('acctNo');String sql = "SELECT acctBal FROM accounts WHERE acctNo = '?'"; 6

HTML

Page 7: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

Right Approach<input type="radio" name="acctIndex" value="1" />Gold Credit Card<input type="radio" name="acctIndex" value="2" />Platinum Credit Card

String acctNo = acct.getCardNumber(getParameter('acctIndex'))String sql = "SELECT acctBal FROM accounts WHERE acct_id = '?' AND acctNo ='?'";

7

HTML

Page 8: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Display of passwords in form, Autocomplete• Don’t populate password in form<input name="password"

type="password" value="<%=pass%>" />

8

HTML

Page 9: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Ajax Hijacking• Cross Site Scripting: DOM, Poor validation• Dynamic code evaluation: Code, Script

Injection, Unsafe XMLHTTPRequest – eval• Open Redirect• Path Manipulation – dot dot slash attack• Obfuscate Client Side JavaScript. Remember

the jQuery.min, jQuery.dev versions

9

JavaScript

Page 10: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• jQueryUnsafe usagevar txtAlertMsg = "Hello World: ";var txtUserInput = "test<script>alert(1)<\/script>";$("#message").html( txtAlertMsg +"" + txtUserInput + "");

Safe usage (use text, not html)$("#userInput").text( "test<script>alert(1)<\/script>"); <-- treat user input as text 10

JavaScript

Page 11: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Use of =, != for null comparison• Ignoring exception – try & catch• Persistent Cross Site Scripting• Use parameterized statements, validate

input before string concatenation in dynamic SQL’s in stored procedures

• Avoid xp_cmdshell• Never store passwords in plaintext

11

SQL

Page 12: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database

12

SQL

Page 13: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• The Java libraries (java.lang, java.util etc, often referred to as the Java API) are themselves written in Java, although methods marked as native. The Sun JVM is written in C, JVM running on your machine is a platform-dependent executable and hence could have been originally written in any language. The Oracle JVM (HotSpot) is written in the C++ programming language. Java Compiler provided By Oracle is written in JAVA itself. Many Java vulnerabilities are really C vulnerabilities that occur in an implementation of Java.

13

About Java

Page 14: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Secure data types – char[], GuardedString• Zip Bombsprivate static final int LINE_LIMIT = 1000000;

int totalLinesRead = 0;while ((s = reader.readLine()) != null) {

doSomethingWithLine(s);totalLinesRead++;

if (totalLinesRead > LINE_LIMIT) {throw new Exception("File being read is too big.");

}}

14

Java

Page 15: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Do not ignore values returned by methods.private void deleteFile(){

File tempFile = new File(tempFileName);if (tempFile.exists()) {

if (!tempFile.delete()) {// handle failure to delete the

file}

}}

15

Java

Page 16: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Release resources in all cases. The try-with-resource syntax introduced in Java SE 7 automatically handles the release of many resource types.

try (final InputStream in = Files.newInputStream(path)) {

handler.handle(newBufferedInputStream(in));}

16

Java - DOS

Page 17: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Billion laughs attack - XML entity expansion causes an XML document to grow dramatically during parsing.

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

DocumentBuilder parser = dbf.newDocumentBuilder();parser.parse(xmlfile);

17

Java

Page 18: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Add security wrapper around native method calls – use JNI defensively

• Make public static fields final• java.lang.SecurityManager – policy• In Struts deny direct jsp access explicitly• Use SecureRandom for PRNG, 128 bit lengthSecureRandom random = newSecureRandom();byte bytes[] = new byte[20];random.nextBytes(bytes);

18

Java

Page 19: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• JSP Source code disclosure• Non-Final classes let an attacker extend a

class in a malicious manner• Packages are by default open, not sealed,

which means a rogue class can be added to your package

• Check uploaded file header than just extension alone

https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf

19

Java

Page 20: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Override the clone method to make classes unclonable unless required. Cloning allows an attacker to instantiate a class without running any of the class constructors.

20

Java Cloning

Page 21: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Define the following method in each of your classes:

public final Object clone() throwsjava.lang.CloneNotSupportedException {throw newjava.lang.CloneNotSupportedException();}

21

Java Cloning

Page 22: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• If a clone is required, one can make one’s clone method immune to overriding by using the final keyword:

public final Object clone() throwsjava.lang.CloneNotSupportedException {return super.clone();}

22

Java Cloning

Page 23: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Unfavour serialization of objects containing sensitive information – transient fields

private final voidwriteObject(ObjectOutputStream out)throws java.io.IOException {throw new java.io.IOException("Object cannot be serialized");}

23

Java Serialization

Page 24: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Prevent deserialization of objects containing sensitive information

private final voidreadObject(ObjectInputStream in)throws java.io.IOException {throw new java.io.IOException("Class cannot be deserialized");}

24

Java Deserialization

Page 25: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• deny access by default

isAdmin = false;try {

codeWhichMayFail();isAdmin = isUserInRole(“Administrator”);

}catch (Exception ex) {

log.write(ex.toString());}

25

Java

Page 26: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

26

Return after sendRedirect

Page 27: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Response splitting allows an attacker to take control of the response body by adding extra CRLFs into headers

String author = request.getParameter(AUTHOR_PARAM);...Cookie cookie = new Cookie("author", author);cookie.setMaxAge(cookieExpiration);response.addCookie(cookie);

27

Response Splitting

Page 28: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

If an attacker submits a malicious string, such as “Rajesh P\r\nHTTP/1.1 200 OK\r\n...", then the HTTP response would be split into two responses of the following form:

HTTP/1.1 200 OK...Set-Cookie: author=Rajesh P

HTTP/1.1 200 OK...Clearly, the second response is completely controlled by the attacker and can be constructed with any header and body content desired.

Response Splitting

Page 29: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

Attacker ProxyWeb Server

302302

200 (Gotcha!)

1st attacker request (response splitter)

1st attacker request (response splitter)

request/account?id=victim

200 (Gotcha!)

200 (Victim’s account data)

Victim

request/index.html

request/index.html

200 (Victim’s account data)

Response Splitting

Page 30: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• How to Identify new vulnerability disclosures in Java? – NVD, CVE

• Always remove older versions of Java on devices while updating to the new secure version

30

Miscellaneous

Page 31: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

The OWASP Enterprise Security API

Custom Enterprise Web Application

Enterprise Security API

Au

the

nti

ca

tor

Use

r

Acce

ssC

on

tro

lle

r

Acce

ssR

efe

ren

ce

Ma

p

Va

lid

ato

r

En

co

de

r

HT

TP

Uti

liti

es

En

cry

pto

r

En

cry

pte

dP

rop

ert

ies

Ra

nd

om

ize

r

Ex

ce

pti

on

Ha

nd

lin

g

Lo

gg

er

Intr

usio

nD

ete

cto

r

Se

cu

rity

Co

nfi

gu

rati

on

Existing Enterprise Security Services/Libraries31

Page 32: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

Validate:

getValidDate()

getValidCreditCard()

getValidInput()

getValidNumber()

Validating Untrusted Input / Output

BackendController Business Functions

User Data Layer

PresentationLayer

Validate:

getValidDate()

getValidCreditCard()

getValidSafeHTML()

getValidInput()

getValidNumber()

getValidFileName()

getValidRedirect()

safeReadLine()

Validation

Engine

Validation

Engine

Page 33: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

OWASP Top Ten Coverage

33

OWASP Top Ten

A1. Cross Site Scripting (XSS)

A2. Injection Flaws

A3. Malicious File Execution

A4. Insecure Direct Object Reference

A5. Cross Site Request Forgery (CSRF)

A6. Leakage and Improper Error Handling

A7. Broken Authentication and Sessions

A8. Insecure Cryptographic Storage

A9. Insecure Communications

A10. Failure to Restrict URL Access

OWASP ESAPI

Validator, Encoder

Encoder

HTTPUtilities (upload)

AccessReferenceMap

User (csrftoken)

EnterpriseSecurityException, HTTPUtils

Authenticator, User, HTTPUtils

Encryptor

HTTPUtilities (secure cookie, channel)

AccessController

Page 34: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Disgruntled staff• Unintentional program execution• Identify Training need, Certification• Urgent and Frequent patches• Selection of Third Party Libraries• “Drive by” attacks, such as side

effects or direct consequences of a virus, worm or Trojan attack

34

Why Static Code Analysis

Page 35: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

• Categories of Vulnerability Sources• URL, Parameter Tampering• Header Manipulation• Cookie Poisoning

• Categories of Vulnerability Sinks• SQL, XPath, XML, LDAP Injection• Cross-site Scripting• HTTP Response Splitting• Command Injection• Path Traversal

35

LAPSE+Static Code Analysis

Page 36: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

36

Free Static Analysis Tools

Page 37: Java Secure Coding Practices

The OWASP Foundationhttp://www.owasp.org

Thank you!Until next time, stay [email protected]://www.facebook.com/OWASPKerala

https://www.twitter.com/owasp_kerala