Getting to ASVS 2 - Balancing practicality with security

GETTING TO ASVS 2
BALANCING PRACTICALITY WITH SECURITY
Created by at
Joeri Sebrechts MCS

View Slide

SECURITY IS A PROCESS
Part of the development process

View Slide

BEGINNING THE PROCESS
2003: MCS starts development of PHP apps
2008: first warning signals, some corrections
2009: customers tell us an uncomfortable truth
After some digging we figure out a few more

View Slide

UNCOMFORTABLE TRUTH #1
There is no absolute security

View Slide

MOST SECURE DATA CENTER IN THE WORLD

View Slide

DESIGN SPEC: ABSOLUTELY SECURE
Biochem-filtered air supply
Autonomous water supply
Self-sufficient for 1 month
Withstand 30 MT nuclear blasts
Engineered for earthquakes
EMP-proof
“ designed to withstand attack by all
foreseeable weapons ”

View Slide

BUT...
Why?
Too expensive, didn't scale
“ The Cheyenne Mountain Realignment
moved NORAD/USNORTHCOM operations
to Peterson AFB in 2006 from the Cheyenne
Mountain nuclear bunker which was placed
on warm standby ”

View Slide

A non-trivial system is either open to attack
or too expensive to maintain
Complex systems must be assumed to be broken

View Slide

- Bruce Schneier
“ Attacks always get better;
they never get worse. ”

View Slide

SQL INJECTION
1998: first mentioned in Phrack
2001: SANS institute paper
2002: documented flaw in Guess site
2004: OWASP top ten #6
2007: sqlmap enables automated attack
2008: automated attack hits 500.000 sites
2010: OWASP top ten #1
2013: 30% of web apps vulnerable

View Slide

PASSWORD CRACKING
1. MD5
2. Rainbow tables
3. Salting, SHA-1
4. "Deep Crack" FPGA
5. SHA-2
6. GPU-acceleration
7. Bcrypt instead of SHA
8. ...
Hashcat

View Slide

Attacks only get "better"
"Secure web development" is a moving target

View Slide

Everyone is a target

View Slide

SURELY NOT MY APP?
All apps are a target:
E-mail addresses (1€/1K)
Account credentials
Privilege escalation
Automated scans
Spear fishing
Watering hole
Just for fun

View Slide

Everybody gets hacked

View Slide

LIKE WHO?
LinkedIn: 6 million passwords stolen
watering hole attack:
Microsoft, Facebook, Apple and Twitter
State-sponsored corporate espionage:
,
NMBS: 1.5 million customer records leaked
But also bakkerseghers.be
and 120 other sites (by one guy)
iPhoneDevSDK
APT1 DeepPanda

View Slide

RECAP
1. There is no absolute security
2. Attacks only get better
3. Everyone is a target
4. Everyone gets hacked
So ... what now?

View Slide

View Slide

AFTER THE PANIC
Sure
Sure But
But
No absolute security Reasonable security
Attacks get better No excuse for not defending
Everyone's a target Be better than the other guy
Everyone gets hacked Don't make it too easy
Figure out a step-by-step plan

View Slide

STEP 1: STOP HITTING YOURSELF

View Slide

Our SQL code was in a bad state
f
u
n
c
t
i
o
n g
e
t
M
o
d
u
l
e
D
i
r
(
$
p
_
d
b
, $
p
_
s
t
r
M
o
d
u
l
e
C
o
d
e
)
{
$
s
t
r
M
o
d
u
l
e
D
i
r = "
"
;
$
q
r
y = "
S
E
L
E
C
T
\
n
" .
" M
O
D
U
L
E
_
D
I
R
E
C
T
O
R
Y
\
n
" .
"
F
R
O
M
\
n
" .
" W
E
B
_
M
O
D
U
L
E
S
\
n
" .
"
W
H
E
R
E
\
n
" .
" M
O
D
U
L
E
_
I
D = (
\
n
" .
" S
E
L
E
C
T M
O
D
U
L
E
_
I
D
\
n
" .
" F
R
O
M M
O
D
U
L
E
S
\
n
" .
" W
H
E
R
E M
O
D
U
L
E
_
C
O
D
E = '
" . $
p
_
s
t
r
M
o
d
u
l
e
C
o
d
e . "
'
\
n
" .
" )
"
;
$
s
t
a
t
e
m
e
n
t = o
c
i
p
a
r
s
e
(
$
p
_
d
b
, $
q
r
y
)
;
o
c
i
e
x
e
c
u
t
e
(
$
s
t
a
t
e
m
e
n
t
, O
C
I
_
D
E
F
A
U
L
T
)
;
i
f (
o
c
i
f
e
t
c
h
i
n
t
o
(
$
s
t
a
t
e
m
e
n
t
, $
r
e
s
u
l
t
, O
C
I
_
A
S
S
O
C + O
C
I
_
R
E
T
U
R
N
_
N
U
L
L
S
)
)
$
s
t
r
M
o
d
u
l
e
D
i
r = $
r
e
s
u
l
t
[
"
M
O
D
U
L
E
_
D
I
R
E
C
T
O
R
Y
"
]
;
o
c
i
f
r
e
e
s
t
a
t
e
m
e
n
t
(
$
s
t
a
t
e
m
e
n
t
)
;
r
e
t
u
r
n $
s
t
r
M
o
d
u
l
e
D
i
r
;
}

View Slide

Centralized DB API, based on Zend_Db
f
u
n
c
t
i
o
n g
e
t
M
o
d
u
l
e
D
i
r
(
$
p
_
s
t
r
M
o
d
u
l
e
C
o
d
e
)
{
$
d
b = M
C
S
D
B
:
:
G
e
t
Z
e
n
d
D
B
C
o
n
n
e
c
t
i
o
n
(
)
;
$
q
r
y = "
S
E
L
E
C
T
\
n
" .
" M
O
D
U
L
E
_
D
I
R
E
C
T
O
R
Y
\
n
" .
"
F
R
O
M
\
n
" .
" W
E
B
_
M
O
D
U
L
E
S
\
n
" .
"
W
H
E
R
E
\
n
" .
" M
O
D
U
L
E
_
I
D = (
\
n
" .
" S
E
L
E
C
T M
O
D
U
L
E
_
I
D
\
n
" .
" F
R
O
M M
O
D
U
L
E
S
\
n
" .
" W
H
E
R
E M
O
D
U
L
E
_
C
O
D
E = :
c
o
d
e \
n
" .
" )
"
;
r
e
t
u
r
n $
d
b
-
>
f
e
t
c
h
O
n
e
(
$
q
r
y
, a
r
r
a
y
(
"
c
o
d
e
" =
> $
p
_
s
t
r
M
o
d
u
l
e
C
o
d
e
)
)
;
}

View Slide

LIB.CORE.PHP
File included at the start of every request
Session management
CSRF protections
Escaping / encoding / decoding
For example, secure HTML entity encoding
URL / path functions
f
u
n
c
t
i
o
n T
o
H
T
M
L
(
$
p
_
s
t
r
V
a
l
u
e
) {
r
e
t
u
r
n s
t
r
_
r
e
p
l
a
c
e
(
"
/
"
, "
&
#
x
2
F
;
"
,
@
h
t
m
l
e
n
t
i
t
i
e
s
(
$
p
_
s
t
r
V
a
l
u
e
, E
N
T
_
Q
U
O
T
E
S
, "
U
T
F
-
8
"
)
)
;
}

View Slide

USED UTF-8 THROUGHOUT
Character set conversions are an XSS minefield.
Always send a charset header
i
n
i
_
s
e
t
(
"
d
e
f
a
u
l
t
_
c
h
a
r
s
e
t
"
, "
U
T
F
-
8
"
)
;
Used mbstring functions everywhere
m
b
s
t
r
i
n
g
.
f
u
n
c
_
o
v
e
r
l
o
a
d = 7
Standardized web services (JSON-RPC)
Zend_Db: charset => "AL32UTF8"
Moved to JS-based UI (single page app)

View Slide

BARE MINIMUM: OWASP TOP TEN
The absolute minimum level of security in web development:
Understand the issues
and how to detect / avoid them.
Use development practices that reduce risk:
Parameterized queries (or ORM)
Use a framework with proper session handling
CSRF defenses on every request
Always work in UTF-8
Read the , adapt code to match
Always use HTTPS
Audit existing code (as time permits)
OWASP top ten
XSS cheat sheet

View Slide

STEP 2: ADAPT THE QA PROCESS

View Slide

MCS SECURITY ASSURANCE PROCESS
Design reviews with eye on security
Manual code reviews of all commits (for security)
Issues are tracked and solved as bug reports.
Standardized reporting
Automated code scans at build time (custom tooling)

View Slide

STEP 3: ASVS 1
Establishing a baseline level of security

View Slide

OWASP APPLICATION SECURITY VERIFICATION STANDARD
Checklist to benchmark the state of a codebase,
organized into levels (each level adds requirements).
Level 1: automated verification
Protect against automated attacks
Level 2: manual verification
Protect against amateur attackers
Level 3: design verification
Protect against expert attackers
Level 4: internal verification
Protect human lives

View Slide

ASVS LEVEL 1
Document libraries and components
Check for proper authentication at page level
Basic session hijacking defenses
Editing URL's cannot bypass security
Sanitize your inputs
Context-appropriate encoding (HTML, CSS, ...)
Don't log DB passwords in error messages
Disable autocomplete in sensitive fields
Specify content type headers
...

View Slide

ASVS 1 EXAMPLE
Chapter 5: input validation

View Slide

EXAMPLE: POSITIVE INPUT VALIDATION
Initial solution:
validation library, developers told to use it
Problem:
“V5.2: Verify that a positive validation
pattern is defined and applied to all input.”
p
u
b
l
i
c s
t
a
t
i
c f
u
n
c
t
i
o
n n
e
w
T
r
a
n
s
a
c
t
i
o
n
D
o
c
u
m
e
n
t
(
$
p
_
s
t
r
T
r
a
n
s
a
c
t
i
o
n
T
y
p
e
, $
p
_
a
r
r
D
e
f
a
u
l
t
s = N
U
L
L
)
{
/
/ T
O
D
O
: A
d
d i
n
p
u
t v
a
l
i
d
a
t
i
o
n
.
.
.
}

View Slide

SECOND SOLUTION: UNIFIED SERVICES
Type and validation rules specified in annotations
Service layer does type casting and validation
Service throws error for invalid type annotations
Auto-generated SOAP WSDL
Accurate web service documentation "for free"
/
*
*
* R
e
t
u
r
n a t
e
m
p
l
a
t
e f
o
r a n
e
w t
r
a
n
s
a
c
t
i
o
n d
o
c
u
m
e
n
t
*
* @
p
a
r
a
m s
t
r
i
n
g $
t
r
a
n
s
a
c
t
i
o
n
T
y
p
e
* @
I
n
A
r
r
a
y [
"
G
o
o
d
s I
s
s
u
e
"
, "
G
o
o
d
s R
e
c
e
i
p
t
"
, .
.
.
]
*
* @
p
a
r
a
m D
T
O
_
S
t
o
c
k
_
T
r
a
n
s
a
c
t
i
o
n
D
o
c
u
m
e
n
t
D
e
f
a
u
l
t $
d
e
f
a
u
l
t
s
*
* @
r
e
t
u
r
n D
T
O
_
S
t
o
c
k
_
T
r
a
n
s
a
c
t
i
o
n
D
o
c
u
m
e
n
t
*
/
p
u
b
l
i
c f
u
n
c
t
i
o
n n
e
w
T
r
a
n
s
a
c
t
i
o
n
D
o
c
u
m
e
n
t
(
$
t
r
a
n
s
a
c
t
i
o
n
T
y
p
e
, $
d
e
f
a
u
l
t
s = N
U
L
L
)
{
.
.
.
}

View Slide

DEMO
Run
r
p
c
(
'
p
i
n
g
'
, '
p
i
n
g
O
b
j
e
c
t
'
, [
{
k
e
y
: 1
0
}
]
, f
u
n
c
t
i
o
n
(
r
e
s
p
o
n
s
e
) {
l
o
g
(
r
e
s
p
o
n
s
e
)
;
}
)
;
/
*
*
* @
p
a
r
a
m D
T
O
_
P
i
n
g
O
b
j
e
c
t $
m
i
r
r
o
r
* @
r
e
t
u
r
n D
T
O
_
P
i
n
g
O
b
j
e
c
t
*
/
f
u
n
c
t
i
o
n p
i
n
g
O
b
j
e
c
t
(
D
T
O
_
P
i
n
g
O
b
j
e
c
t $
m
i
r
r
o
r = N
U
L
L
) {
r
e
t
u
r
n $
m
i
r
r
o
r
; }
c
l
a
s
s D
T
O
_
P
i
n
g
O
b
j
e
c
t e
x
t
e
n
d
s M
C
S
_
D
a
t
a
T
r
a
n
s
f
e
r
O
b
j
e
c
t {
/
*
*
* @
v
a
r i
n
t P
o
s
i
t
i
v
e i
n
t
e
g
e
r
* @
M
i
n 0
*
/
p
u
b
l
i
c $
k
e
y = 1
;
}

View Slide

STEP 4: ASVS 2
Achieving "reasonable security" at the enterprise level

View Slide

All of ASVS 1 requirements
High-level architecture must be documented
Strong authentication controls
Strong session hijacking defenses
Comprehensive server-side access control
Verify character set behavior
All injection-sensitive code must be audited
Proper cryptographic algorithms
Comprehensive logging of security events
Secure handling of cached data
SSL used for all communication
...

View Slide

DEFENSE IN DEPTH

View Slide

ON-GOING CHALLENGES
Not slacking off on security reviews
Strong authentication
Password strength rules
Correct password hashing algorithm
Two-factor auth
Many clients interacting with DB
Logging - too much vs. too little
Changing automated tools to match practices
Feature requests vs secure architecture
Beyond the web code
(windows codebase, hosting environment, ...)

View Slide

USEFUL LINKS
OWASP , , , ,
It's difficult to navigate, but it's all there
(wiki)
Best book on web security
(RSS)
Insider's view of OWASP community.
Weekly recap of relevant security stories.
Example implementation of annotated type validation.
top ten quick ref cheat sheets ASVS ESAPI
Browser Security Handbook
The Tangled Web
OWASP AppSec Feed
Security Now podcast
github.com/jsebrech/php-o

View Slide

QUESTIONS?
Thank you for listening!
[email protected]
joind.in/8570

View Slide

Getting to ASVS 2 - Balancing practicality with security

Getting to ASVS 2 - Balancing practicality with security

Joeri Sebrechts

Other Decks in Technology

Featured

Transcript