Secure Coding for Java

The OWASP Foundation
http://www.owasp.org

Integrating security & privacy
in a web application project
OWASP Training Day - Ottawa
Feb 27th 2012
Module 2 : Secure Coding

mardi 8 janvier 13

Agenda

•Introduction
•Using OWASP materials
to secure code
•Secure Coding principles
•Code Review

mardi 8 janvier 13

http://www.google.fr/#q=sebastien gioria
➡Head of IT and Security Audit at Groupe Y
➡OWASP France Leader & Founder - Evangéliste
➡ OWASP Global Education Comittee Member
(sebastien.gioria@owasp.org)
➡Leader and technical advisor on the Web App security
group at CLUSIF
Twitter :@SPoint

CISA && ISO 27005 Risk Manager
★More than 15 years of manager and technical leads in differents
firms ; bank, insurance, telecom, startups, ...
★Technical Expertise
★Securing SDLC
★Pentesting
★CodeReview
★Risk management, audits
★Security and Network training

mardi 8 janvier 13

ForeWords
•This is a Training made from my own
experience with a big number of
company using OWASP materials.

•Only the documents from OWASP wiki are
OWASP officials (see https://www.owasp.org)
5

•Some extracts come from document I wrote as
OWASP leader, this is why you could find it
elsewhere.

mardi 8 janvier 13

Majors OWASP publications we
can use
All are on the wiki https://www.owasp.org
All are under GPL or friendly licenses
Majors publications you can use to secure
your projects/SDLC
Top10 reference this 3 guides

Ø OWASP Top10
Ø Auditor/Testing Guide
Ø Code Review Guide Building Code Review
Testing Guide
Guide 12Guide
Ø Building Guide
Ø Application Security Verification
Standard (ASVS)
Application Security Desk Reference (ASDR)
Ø Secure Coding Practices

mardi 8 janvier 13

Learning

13

mardi 8 janvier 13

Learning Contract

13

mardi 8 janvier 13

Learning Contract

Testing

13

mardi 8 janvier 13

Learning Contract Build

Testing

13

mardi 8 janvier 13


Check Testing

13

mardi 8 janvier 13


Check Testing Progress

13

mardi 8 janvier 13


Introduction

mardi 8 janvier 13

Consequences of bad or no
security
• Identity theft
• Hardware theft
• Bad Media coverage
• Customers loss
• Legals/business penalty
• Financials loss
• IT downtime
8
mardi 8 janvier 13

© CLUSIF 2010 - Extrait de la présentation MIPS2010

17

mardi 8 janvier 13

© CLUSIF 2010 - Extrait de la présentation MIPS2010

18

mardi 8 janvier 13

What Verizon (PCI-DSS
company) said ?

© Verizon 2010

11
mardi 8 janvier 13

Verizon Study

© Verizon 2010

12
mardi 8 janvier 13

22

© IBM X-Force 2009 - Extrait du rapport 2009

mardi 8 janvier 13

23

© IBM X-Force 2009 - Extrait du rapport 2009

mardi 8 janvier 13

Vulnerability exposure

26

mardi 8 janvier 13

What you CIO Said : I got a Firewall !

27

mardi 8 janvier 13

What your business user said : I have SSL
based Web Site

28

mardi 8 janvier 13

What your business user said : only the hacker can
attack my website
• Tools are more and more
simples.

• Try a simple request on
google website on SQL
Injection and look at it.

• An attack on a Web Server
cost 100$/200$ per
day on the
underground market.
29

mardi 8 janvier 13

What your user said : a vulnerability
on internal WebApp is not critical.
•No, The web is anywhere, and CSRF, HTML5 CORS
and more can make this completly destructive

•Be aware and share this :
• AJAX doing a lot of things without you
30

•Be aware and share this :
• HTML5 will come with “nice” user functionnality ,
but with big impact on security (WebSocket,
CORS, ...)
mardi 8 janvier 13


OWASP Application Security
Verification Standard

mardi 8 janvier 13

What is ASVS ?
•A standard that provides a basis for the
verification of web applications application-
independent.
•A standard life-cycle model independent.
•A standard that define requirements that can
be applied across applications without
43

special interpretation.

mardi 8 janvier 13

What are ASVS responses ?

•How much trust can be placed in a web
application?
•What features should be built into
security controls?
•How do I acquire a web application that
is verified to have a certain range in
coverage and level of rigor?

mardi 8 janvier 13

ASVS secure controls requirements

Level Level Level Level
Security Area Level 3 Level 4
1A 1B 2A 2B

V1 – Security Architecture Verification Requirements 1 1 2 2 4 5

V2 – Authentication Verification Requirements 3 2 9 13 13 14

V3 – Session Management Verification Requirements 4 1 6 7 8 9

V4 – Access Control Verification Requirements 5 1 12 13 14 15

V5 – Input Validation Verification Requirements 3 1 5 7 8 9

V6 – Output Encoding/Escaping Verification Requirements 0 1 2 8 9 10

V7 – Cryptography Verification Requirements 0 0 2 8 9 10

V8 – Error Handling and Logging Verification Requirements 1 1 2 8 8 9

V9 – Data Protection Verification Requirements 1 1 2 3 4 4

V10 – Communication Security Verification Requirements 1 0 3 6 8 8

V11 – HTTP Security Verification Requirements 3 3 6 6 7 7

V12 – Security Configuration Verification Requirements 0 0 0 2 3 4

V13 – Malicious Code Search Verification Requirements 0 0 0 0 0 5

V14 – Internal Security Verification Requirements 0 0 0 0 1 3

Totals 22 12 51 83 96 112

23
mardi 8 janvier 13

But ASVS stand for
Verification ?
•ASVS just said functionals needs for
controls.
•We could use it as a Secure Coding Policy.

★Don’t be medium(ASVS Level1/2),
just target excellence (ASVS Level
4)
24
mardi 8 janvier 13

Using ASVS as a secure
coding policy
ASVS : Verify that all password fields do not echo the
user’s password when it is entered.
➡ All Password fields must be define as
HTML passwd fields and must not echo
user passwd.
➡ All login forms must include
autocomplete=off tag
ASVS : Verify that all input validation is performed on
the server side.
➡ Performs all input validation on the server.
Nothing in the browser
25
mardi 8 janvier 13

Positive attitude
Negative
 The tester shall search for XSS holes
Positive
 Verify that the application performs input validation and output
encoding on all user input

See: http://www.owasp.org/index.php/
XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
56

mardi 8 janvier 13


OWASP Secure
Coding Practices

mardi 8 janvier 13

OWASP Secure Coding
Practices
•Small document (only 9 pages)
•Could be use as an simple checklist for
your policy.
•Could be use together with ASVS or
alone.
•More technical and deeper approach
than ASVS .
•Wrote and use by Boeing :)
28
mardi 8 janvier 13

Secure Coding Practices
Contents
•Input Validation •Data Protection
•Output Encoding •Communication Security
•Authentication and •System Configuration
Password Management
•Database Security
•Session Management •File Management
•Access Control •Memory Management
•Cryptographic Practices •General Coding Practices
•Error Handling and
Logging

29
mardi 8 janvier 13

Now the torture room

30
mardi 8 janvier 13


Let talk Secure
Coding now
(extracts from OWASP Secure Coding Practices/
OWASP CheatSheets OWASP ASVS, ...)

mardi 8 janvier 13

KISS : Keep it Short
and Simple

32
mardi 8 janvier 13

Some secures principles to
follow
•Deep defense of application is
mandatory
•Following less privileges is the best
solution
•Segregate duty more that user think
➡Remember that application need to
answer user needs and not security
pleasure.
33
mardi 8 janvier 13

Deep defense of an Application (example)

Secure Good crash mecanisms
Preventing parameters Critical data protections
configuration
thefts

User auth

Web App Server SGBD
Server
Fi
Browser re
w Web
Apps Applica5on
all

Authorisation Authorisation and Logs/Audit of
Input
• Critical data transport and authentication transactions Critical data protections
Validation
protection authentication
• Preventing session and ID
theft
70

mardi 8 janvier 13

Fail securely
Don’t give user technical details of the crash.
Example :
• 404

• 500

35
mardi 8 janvier 13

Fail Securely

36
mardi 8 janvier 13

Don’t try to make obscure things

72

mardi 8 janvier 13


GEOPORTAIL

72

mardi 8 janvier 13


GOOGLE MAPS

72

mardi 8 janvier 13

Controls
• Controls need :
• to be simple
• to be used correctly
• functional
• present in every part of the application
74

Bad understanding of a control result of unused
it by developers and application will be
vulnerable.

mardi 8 janvier 13

Minimals controls to have
You must have at least this components in your
application :
• Authentication
• Authorization
• Logging and audit
• Secure Storage 75

• Secure transport
• Secure input and output manipulation of data

mardi 8 janvier 13


Authentication

mardi 8 janvier 13

Implement good passwd
strategy
Password length
- Categorize applications :
• Important : at least 6 characters
• Critical : at least 8 characters and perhaps multi-factors
authentication
• High Critical : at least 14 characters and multi-factors
authentication
Password strength
- Implement passwd complexity with previous categories
• at least : 1 upper, 1 lower, 1 digit, 1 special
• don’t allow dictionnary passwd
• don’t allow continuous characters
41
mardi 8 janvier 13

Implement good passwd
strategy
•Let the user choose it
•Force the user to change it regulary, and add no
reuse capability.
•Don’t allow too much “I forgot my passwd”
•Don’t allow change of passwd without user
approval; require actual passwd from the user and
more for high critical.
•Add sleep strategy !
•Add detection of misuse strategy !
•Don’t store passwd in clear !!!!! use hash !
42
mardi 8 janvier 13

Multi-Factor authentication

•Passwds are bad
•Passwds are guessable
•Multi-factor combine:
• something you have (token, mobile, ...)
• something you know (details about you,
passwd, ...)
• sometime, something you are (biometrics)
• Use it for high critical applications.
43
mardi 8 janvier 13

Implement good global
strategy
•Ask second authentication for critical
transactions (with multi-factor auth...)
•Force authentication to be in TLS/SSL
•Regenerate Session ID after
authentication
•Force Session ID to be “secure”
•Limiting forgotten passwd,change of
login/passwd
44
mardi 8 janvier 13

Good Passwd strategy

45
mardi 8 janvier 13

How to do ?
•Authenticate all pages but not public pages (login,
logout, help, ....)
•Don’t allow more than one authentication
mecanism
•Authenticate on the SERVER
•Simply send back “user or passwd mismatch” and
nothing else after a failed authentication.
•Logged all failed and all correct authentication
•After each authentication give the user the last
status of his authentication.
46
mardi 8 janvier 13


Exercice 1.1
Adding secure Authentication to ePoney

mardi 8 janvier 13

Exercice 1.1 - Ideas
Setup Passwd strategy
• Length
• Complexity
Fighting brute-force
• in-session limitation
• out of session limitation

48
mardi 8 janvier 13


Session
Management

mardi 8 janvier 13

Session
•Use Default Java Framework Generator
•Use other name than the default name of the
Framework (rename JSESSIONID...)
•Force transport of ID authentication on SSL/TLS.
•Don’t allow Session ID in URL !
•If using cookie :
• Secure Cookie
• HTTPOnly Cookie
• Limiting path + domain
• Max Age and expiration
50
mardi 8 janvier 13

Session tricky
Automatic expiration
• categorize applications :
• default : 1 hour
• critical (some transaction) : 20mns
• high critical (financials or account impact) : 5mns
Renew Session ID after any privilege change
Don’t allow simultaneous logon
Add Session Attack Detection
• add in-session tips : ip of session, other random
number, ...
51
mardi 8 janvier 13

Browser defenses
Bind JavaScript events to close session
• on window.close()
• on window.stop()
• on window.blur()
• on window.home()
Use Javascripts timer to automatic close session in high
critical applications
Disable WebBrowser Cross-tab Session if possible...(bad
user experiences....)
• If you use cookie, this is not possible !!!!
52
mardi 8 janvier 13

Using Servlet 3.0 ?
<session-‐config>

<cookie-‐config>

<http-‐only>true</http-‐only>

<secure>true</secure>

</cookie-‐config>
</session-‐config>

53
mardi 8 janvier 13

Access Controls

107

mardi 8 janvier 13

Remember

mardi 8 janvier 13

Remember
(1)Without access control, you can’t
control the user in your application

mardi 8 janvier 13

Remember
(1)Without access control, you can’t
control the user in your application
(2)Client inputs are EVIL

mardi 8 janvier 13

Authentication && Authorization

• Two Levels of authentication
and authorization are
needed
–In the Application
–In infrastructure
App Server SGBD

Role
A Connexion Table A + duty A Table
A

Connexion Table B + Duty B
Role
B Table
B

mardi 8 janvier 13

Authorization
Have in mind the rule :
• Nothing by default
Centralize all authorization code on the SERVER
If client state are mandatory, use encryption and
integrity checking on the server side to catch
state tampering.
Limit number of transaction per user at a interval
time.

57
mardi 8 janvier 13

Authorization
Enforce :
• protection of URL to authorized account only
• protection of function to authorized account only
• protection of file access to authorized account only
Application need to terminate session when authorization failed.
Split administrative and user authorization
Enforce dormant account :
• loss privileges.
• “disable account”
• alerts

58
mardi 8 janvier 13

Exercice
Make que application mono-session per
user

59
mardi 8 janvier 13

Input Validation
Ensure all data validation are done on THE SERVER.
• If you do something on client side we can said
you do “painting”
Classify your data :
• Trusted Data
• Untrusted Data
Conduct trusted path.
Centralize your data validation
Use parametrize query when exists (SQL)

60
mardi 8 janvier 13

Border validation
Consider validating data along all the entry
points of your Application border

61
mardi 8 janvier 13

Input Validation
Use proper characters set for all input
Encode all data to the same character set before doing
anything <=>Canonicalize
Reject all not validated datas
Validate data :
• expected type (convert as soon as possible to Java Types)
• expected range
• expected length
• expected values
• expected “white list” if possible

62
mardi 8 janvier 13

Input Validation
Be careful of using “hazardous” characters (ex:
<>’,”!(+)& %.)
Add specific validation :
• check for null bytes (%00)
• check for new lines (%0D, %0A, n, r, ...)
• check for dot-dot-slashes (../)

63
mardi 8 janvier 13

Be careful of encoding for specific validation...

<script>alert(XSS);</script>
URL
%3c%73%63%72%69%70%74%3e%61%6c
%65%72%74%28%58%53%53%29%3b%3c%2f%73%63%72%69%70%74%3e
%0a
HTML
<script>ale&#x7
2;t(XSS);</sc&#x
72;ipt>

UTF-8
%u003c%uff53%uff43%uff52%uff49%uff50%uff54%u003e%uff41%uff4c
%uff45%uff52%uff54%uff08%uff38%uff33%uff33%uff09%u003c
%u2215%uff53%uff43%uff52%uff49%uff50%uff54%u003

One space ?
<script>alert(XSS);</script>

mardi 8 janvier 13

Validating Datas

124

mardi 8 janvier 13

SQL => bad

125

mardi 8 janvier 13

SQL => a little bit better

126

mardi 8 janvier 13

XML => bad

127

mardi 8 janvier 13

XML => Validating

128

mardi 8 janvier 13

Better, a XML schema
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="item">

<xs:complexType>

<xs:sequence>

<xs:element name="description" type="xs:string"/>

<xs:element name="price" type="xs:decimal"/>

<xs:element name="quantity" type="xs:integer"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

mardi 8 janvier 13

XML => XML Parser

mardi 8 janvier 13

LDAP => bad

131

mardi 8 janvier 13

LDAP => better

132

mardi 8 janvier 13

Using OWASP ESAPI

74
mardi 8 janvier 13


Output Encoding

mardi 8 janvier 13

Output encoding
It’s a Defense in depth mechanism
Encode ON THE SERVER
Centralize the encoder functions
Sanitize all data send to the client
• HTMLEncode is a minimum but did
not work on all cases

76
mardi 8 janvier 13

Essai 1 => bad

137

mardi 8 janvier 13

Essai 2 => it’s bad, but better than nothing

138

mardi 8 janvier 13

A good solution with a robust
Sanitizer :)

139

mardi 8 janvier 13


Error Logging

mardi 8 janvier 13

Error Handling
Your Application will crash !
Catch all exceptions without exception (remember the null pointer exception !)
• Clean all exception code of sensitive datas
• Don’t give user any details about crash, just said “It’s a crash, try again later”
Logs are sensitive, you MUST PROTECT THEM
Log :
• input validation failures
• authentication request; especially failures
• access control failures
• systems exceptions
• administrative functionality
• crypto failures
• invalid/expired session token access

81
mardi 8 janvier 13

Logging/Errors
Split your logs with categories, examples :
• Access
• Error
• Debug
• Audit
Use log4j for standard logging

82
mardi 8 janvier 13

Log4J Example
import com.sec.dev;

// Import log4j classes.
import org.apache.log4j.Logger;
import org.apache.log4j.BasicConfigurator;

public class SecLogger {

// Define a static logger variable so that it references the
// Logger instance named "MyApp".
static Logger logger = Logger.getLogger(MyApp.class);

public static void main(String[] args) {

// Set up a simple configuration that logs on the console.
BasicConfigurator.configure();

logger.setLevel(Level.DEBUG); // optional if log4j.properties file not used
// Possible levels: TRACE, DEBUG, INFO, WARN, ERROR, and FATAL

logger.info("Entering application.");
Bar bar = new Bar();
bar.doIt();
logger.info("Exiting application.");
}
}

83
mardi 8 janvier 13

Exercice
Add correct logging to ePoney
Verify error handling implementation

84
mardi 8 janvier 13

Bad handling of Exception

144

mardi 8 janvier 13

Good handling of exception

<error-page> 145

<exception-type>java.lang.Throwable</
exception-type>
<location>/error.jsp</location>
</error-page>

mardi 8 janvier 13


Data Protection

mardi 8 janvier 13

Data protection
Protect sensitive datas, don’t store them
in clear.
Store sensitive datas in trusted systems
Don’t use GET request for sensitive data.
Disable client site caching

88
mardi 8 janvier 13

Disable Client Side caching
import
javax.servlet.*;
import
javax.servlet.http.HttpServletResponse;
import
java.io.IOException;
import
java.util.Date;

public
class
CacheControlFilter
implements
Filter
{

public
void
doFilter(ServletRequest
request,
ServletResponse
response,

FilterChain
chain)
throws
IOException,
ServletException
{

HttpServletResponse
resp
=
(HttpServletResponse)
response;

resp.setHeader("Expires",
"Tue,
03
Jul
2001
06:00:00
GMT");

resp.setHeader("Last-‐Modified",
new
Date().toString());

resp.setHeader("Cache-‐Control",
"no-‐store,
no-‐cache,
must-‐revalidate,
max-‐age=0,
post-‐check=0,
pre-‐check=0");

resp.setHeader("Pragma",
"no-‐cache");

chain.doFilter(request,
response);

}

}

web.xml
<filter>

<filter-‐name>SetCacheControl</filter-‐name>

<filter-‐class>com.sec.dev.cacheControlFilter</filter-‐class>
</filter>

<filter-‐mapping>

<filter-‐name>SetCacheControl</filter-‐name>
<url-‐pattern>/*</url-‐pattern>
</filter-‐mapping>

89
mardi 8 janvier 13


Acces to FileSystem

mardi 8 janvier 13

Absolute Path is bad

151

mardi 8 janvier 13

Canonicalisation is good

92
mardi 8 janvier 13


Secure
Communications

mardi 8 janvier 13

Secure Communications
Use TLS/SSL :
• at least SSL v3.0/TLS 1.0
• minimum of 128bits encryption
• use secure crypto : AES is good
Don’t expose critical data in the URL
Failed SSL/TLS communications should not fall
back to insecure
Validate certificate when used
Protect all page, not just logon page !

94
mardi 8 janvier 13

Force TLS/SSL Response
Use HTTP Strict Transport Security (HSTS).
• Available on some browsers
• draft IETF : http://tools.ietf.org/html/
draft-ietf-websec-strict-transport-
sec-04
HttpServletResponse
...;
response.setHeader("Strict-‐Transport-‐Security",
"max-‐age=7776000;

includeSubdomains");

95
mardi 8 janvier 13


Administrative
interfaces

mardi 8 janvier 13

Administratives interfaces
Use multi-factor authentication system
Log transaction in other log files than user.
Enforce logging, examples :
• transaction on duty
• transaction on user accounts
Be careful of duty :
• Help Desk is not an Administrator !

97
mardi 8 janvier 13


Configuration

mardi 8 janvier 13

site:yale.edu inurl:password

mardi 8 janvier 13

Configuration
Review all properties, configuration files
Be careful of default passwds...
Remove, and not just desactivate, unused
functions/modules
Use sandbox system when available :
Be careful of Java Signed code who
execute with more privileges !

100
mardi 8 janvier 13


Code Review

mardi 8 janvier 13

Why Security Code review /Vulnerability
searching?

102
mardi 8 janvier 13

searching?
✓To find them ?

102
mardi 8 janvier 13

searching?
✓To find them ?
✓To know where there are in the code ?

102
mardi 8 janvier 13

searching?
✓To find them ?
✓To ensure they are not in our code ?

102
mardi 8 janvier 13

searching?
✓To find them ?
✓To ensure they are not in our code ?
✓To conform to legal/business rule ?

102
mardi 8 janvier 13

What is security code
review ?
It’s a tools driven review of your code.
Security Code Review imply :
• Source code access
• Business document access
• Configuration access

103
mardi 8 janvier 13

SQL Injection ?

104
mardi 8 janvier 13

Injection code

105
mardi 8 janvier 13

False
Posi5ve False
Nega5ve Didn’t
ﬁnd

Code
Review 1 1 1

Test 3 3 5

A voir : http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

106
mardi 8 janvier 13

XSS

107
mardi 8 janvier 13

False
Posi5ve False
Nega5ve Didn’t
ﬁnd

Code
Review 2 2 2

Test 5 3 1

A voir : http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

108
mardi 8 janvier 13

Common AuthN & Session Mgt
Reqts

109
mardi 8 janvier 13

Both Have Their Advantages
Pen Testing Pros Code Review Pros

• Requires less •Easier to
specialized expertise •Find all the content
• Easier setup •Find all instances of
certain types of flaws
• Easier to perform •Verify controls are
• Exercises the entire correct
app infrastructure •Verify controls are used
in all the required
• Proves places
vulnerabilities

110
mardi 8 janvier 13


Tools

mardi 8 janvier 13

LAPSE+ is a eclipse plugin to static analysis of code for detecting
vulnerabilities of untrusted data injection in Java EE Applications.

LAPSE+ is inspired by existing lightweight security auditing tools such
as FlawFinder.

Developed by Group of Stanford University.

GPL Software.

112
mardi 8 janvier 13

LAPSE+ Vulnerabilities
Detected
URL Tampering
Cookie Poisoning
Parameter Tampering
Header Manipulation
Cross-site Scripting (XSS)
HTTP Response Splitting
Injections (SQL, Command, XPath, XML, LDAP)
Path Traversal
113
mardi 8 janvier 13

CodePro on ePoney

116
mardi 8 janvier 13


Demo

mardi 8 janvier 13

Now you can protect against him

118
mardi 8 janvier 13

License

119
mardi 8 janvier 13

Secure Coding for Java

Recommended

More Related Content

What's hot (20)

Viewers also liked (13)

Similar to Secure Coding for Java (20)

More from Sébastien GIORIA (20)

Recently uploaded (20)

Secure Coding for Java