1. 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
2. Agenda
•Introduction
•Using OWASP materials
to secure code
•Secure Coding principles
•Code Review
mardi 8 janvier 13
3. 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
4. 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
5. 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
20. 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
31. What you CIO Said : I got a Firewall !
27
mardi 8 janvier 13
32. What your business user said : I have SSL
based Web Site
28
mardi 8 janvier 13
33. 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
34. 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
35. The OWASP Foundation
http://www.owasp.org
OWASP Application Security
Verification Standard
mardi 8 janvier 13
36. 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
37. 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
39. 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
40. 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
41. 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
42. The OWASP Foundation
http://www.owasp.org
OWASP Secure
Coding Practices
mardi 8 janvier 13
43. 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
46. The OWASP Foundation
http://www.owasp.org
Let talk Secure
Coding now
(extracts from OWASP Secure Coding Practices/
OWASP CheatSheets OWASP ASVS, ...)
mardi 8 janvier 13
47. KISS : Keep it Short
and Simple
32
mardi 8 janvier 13
48. 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
49. 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
50. Fail securely
Don’t give user technical details of the crash.
Example :
• 404
• 500
35
mardi 8 janvier 13
52. Don’t try to make obscure things
72
mardi 8 janvier 13
53. Don’t try to make obscure things
GEOPORTAIL
72
mardi 8 janvier 13
54. Don’t try to make obscure things
72
mardi 8 janvier 13
55. Don’t try to make obscure things
GOOGLE MAPS
72
mardi 8 janvier 13
56. 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
57. 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
59. 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
60. 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
61. 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
62. 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
64. 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
65. The OWASP Foundation
http://www.owasp.org
Exercice 1.1
Adding secure Authentication to ePoney
mardi 8 janvier 13
66. Exercice 1.1 - Ideas
Setup Passwd strategy
• Length
• Complexity
Fighting brute-force
• in-session limitation
• out of session limitation
48
mardi 8 janvier 13
68. 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
69. 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
70. 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
71. 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
74. Remember
(1)Without access control, you can’t
control the user in your application
mardi 8 janvier 13
75. Remember
(1)Without access control, you can’t
control the user in your application
(2)Client inputs are EVIL
mardi 8 janvier 13
76. 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
77. 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
78. 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
79. Exercice
Make que application mono-session per
user
59
mardi 8 janvier 13
80. 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
81. Border validation
Consider validating data along all the entry
points of your Application border
61
mardi 8 janvier 13
82. 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
83. 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
84. 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
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
100. 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
107. 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
108. Logging/Errors
Split your logs with categories, examples :
• Access
• Error
• Debug
• Audit
Use log4j for standard logging
82
mardi 8 janvier 13
109. 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
110. Exercice
Add correct logging to ePoney
Verify error handling implementation
84
mardi 8 janvier 13
113. Good handling of exception
<error-page> 145
<exception-type>java.lang.Throwable</
exception-type>
<location>/error.jsp</location>
</error-page>
mardi 8 janvier 13
115. 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
122. The OWASP Foundation
http://www.owasp.org
Secure
Communications
mardi 8 janvier 13
123. 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
124. 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
125. The OWASP Foundation
http://www.owasp.org
Administrative
interfaces
mardi 8 janvier 13
126. 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
129. 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
132. Why Security Code review /Vulnerability
searching?
✓To find them ?
102
mardi 8 janvier 13
133. Why Security Code review /Vulnerability
searching?
✓To find them ?
✓To know where there are in the code ?
102
mardi 8 janvier 13
134. Why Security Code review /Vulnerability
searching?
✓To find them ?
✓To know where there are in the code ?
✓To ensure they are not in our code ?
102
mardi 8 janvier 13
135. Why Security Code review /Vulnerability
searching?
✓To find them ?
✓To know where there are in the code ?
✓To ensure they are not in our code ?
✓To conform to legal/business rule ?
102
mardi 8 janvier 13
136. 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
142. False
Posi5ve False
Nega5ve Didn’t
find
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
143. False
Posi5ve False
Nega5ve Didn’t
find
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
144. Common AuthN & Session Mgt
Reqts
109
mardi 8 janvier 13
145. 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
147. 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
