Web application security: how to start?

Web application securitythe first steps towards a secure SDLC

Antonio FontesOWASP Geneva Chapter Leader

Confoo ConferenceMarch 11th 2010, Montreal, CA

2

(coward) disclaimer

• We haven’t found the solution, yet.• Most methodologies are v.1.x and getting

continuous improvements.• You might need more than one point of view

Antonio Fontes / Confoo Conference, Montreal / 2010

3

Agenda - Context

• Some theory– Security expectations in software– Identifying threats and their countermeasures– Coward strategy

• A case study• Conclusion


4

About me

• Antonio Fontes, from Geneva (Switzerland)• >1999: Web developer• >2005: Ethical hacker / Security analyst• >2008: Security & Privacy manager (banking

software ISV)• >2008: OWASP Geneva Chapter Leader • >2010: Information Security Consultant • SANS/CWE Top 25 Most Dangerous

Programming Errors contributorAntonio Fontes / Confoo Conference, Montreal / 2010

About you?

• Coders? • Testers?• Managers?• Ninjas?

6

First things first: THEORY


7

80-20 rule

• Also applies to information security

SQL injections

Authentication & session management

OWASP Top 10


OWASP ASVS

8

what does “secure” mean?


9

Security & Privacy contract

• 1st assurance: CONFIDENTIALITY”Data is protected from unauthorized access.”

• 2nd assurance: INTEGRITY”Data is true and actual.”

• 3rd assurance: AVAILABILITY”Legitimate requests get answers in legitimate time.”

• 4th assurance: TRACEABILITY”You can reconstruct a trustworthy history of any

user’s interactions with your application.”


10

Security & Privacy contract

• 5th assurance: PRIVACY”Personal data is protected both from unauthorized

access but also from unnecessary access.”• 6th assurance: COMPLIANCE

”Data is collected, processed, accessed,stored, archived and destroyed in accordance with Law.”

• 7th assurance: REPUTATION”Security incidents that might potentially occur

won’t harm the organization’s reputation.”


These are what your boss understands!

The 5 others are what you really need to solve ;)

11

the threat

“Nobody wants to hack us.”


12

Who are your threat agents?

• Dumb guy• Show-off guy • « I kill you!» guy• Organized crime• But also…• Competition• Governments


Lower effort

Higher effort

Security features vs. secure features

Security features

Input validation

Output sanitization

Authentication

Authorization

Session management

Errors and exceptions handling

Logging and auditing

Configuration

Cryptography

Transport securityChecklists already solve common problems!

Secure features: STRIDE model

• SPOOFING -> authentication• TAMPERING -> integrity• REPUDIATION -> non-repudiation• INFORMATION DISCLOSURE -> confidentiality• DENIAL OF SERVICE -> availability• ELEVATION OF PRIVILEGES -> authorization

For each asset, ask yourself what nightmares you really don’t want to come true!

15

$$$$ issues


16

Fuzz test

the big picture

Analyze Design Implement Verify Release Support

Product Risk Management Strategy

S&P Risk assessment

Secure design

Attack surface analysis

Secure Coding guidelines

Secure coding tools

Incident responseRisk assessment (attack surface

review)

CERT response

Intranet portal (case studies, news, best practices, secure code repository)

Training operations (secure coding, threat modelling, code analysis,...)

Awareness operations (coffee room, newsletters, posters on the wall, drop OWASP guides on the floor, lunch with devs, etc.)

Identify security requirements

SP3DC (Security and Privacy by Design, Development, Deployment and Configuration)

Secu

rity

Activ

ities

/ S

DLC

Threat modeling

S&P test planning

Unit testingStatic code analysis

S&PTest

Secure configuration and deployment

PenetrationTest


Incident response planning

Final S&P signoff

Release archive

How are big companies doing?

SE1.2: Secure deploymenthost and network security basics are in place

SFD1.1: Security features developmentsecurity features (auth, crypto, session, etc.) are centrally developed and reused.

PT1.1: External penetration testExternal penetration tests bring light to insecure applications and organizations, which need help.

CP1.3: Create a policyDefine a policy that satisfies regulatory & compliance requirements.

blablaSo

urce

: BSI

-mm

(htt

p://

bsi-m

m.c

om/)

Let’s think costs and risk reduction!

18

our own picture

• What is cheap?• What is effective?


19

Fuzz test

our own picture


Product Risk Management Strategy

S&P Risk assessment

Secure design

Attack surface analysis

Secure Coding guidelines

Secure coding tools

Incident responseRisk assessment (attack surface

review)

CERT response

Intranet portal (case studies, news, best practices, secure code repository)

Training operations (secure coding, threat modelling, code analysis,...)

Awareness operations (coffee room, newsletters, posters on the wall, drop OWASP guides on the floor, lunch with devs, etc.)

Identify security requirements

SP3DC (Security and Privacy by Design, Development, Deployment and Configuration)

Secu

rity

Activ

ities

/ S

DLC

Threat modeling

S&P test planning

Unit testingStatic code analysis

S&PTest

Secure configuration and deployment

PenetrationTest


Incident response planning

Final S&P signoff

Release archive

20

S&P test

• You can do it (you, or automated security scanning tools)

• You don’t need to ask (well…….it depends)

• It’s virtually free (for your boss. you lose one or two evenings.)

• You will get a picture – That you can show your management– That will serve as input into your bug tracking tool– If you use a reference (OWASP Top 10?), you can

even monitor progress


21

Threat analysis and modeling

• You can do it (if there is documentation, it’s better)

• You don’t need to ask (well…….it depends)

• It’s virtually free (for your boss. you lose one or two evenings.)

• You will issue recommendations– That will help you and your colleagues build more

secure code.– That you will improve with time.


22

SUMMARY

• Security contract: – 7 rules– 5 security properties that lead to 2 security

concerns• Threat agents• Low-cost SDLC injection phases


23

lazy strategy


24

lazy strategy

• Your goal: staying out of statistics (shame avoidance pattern)

– UK breach investigation report:• 60% of web intrusions: SQL Injection*• 30% of web intrusions: authentication*

– Web hacking incidents database:• 19% : SQL Injection• 11% : authentication attacks

– OWASP Top 10 web application security risks:• Don’t get exposed to one of these attacks!

*: 7Safe - UK Security breach investigations report 2010Antonio Fontes / Confoo Conference, Montreal / 2010

25

lazy strategy (cont’d)

• Don’t be a hero (yet), use checklists!– Start simple and short• Generic items (security features): reduce exposure to

technical attacks– OWASP Application Security Verification Standard– MS Web applications threats and countermeasures security

checklist

• Specific items (secure features): reduce exposure to attacks relating to your business

• Many checklists are already automated:– Use an automatic security scanning tool!!!


26

lazy strategy (cont’d)

• Lazy threat modeling:– List the use cases and identify the most valuable

assets involved with them.– Think about how the assets might be exposed if

the use case goes wrong:• STRIDE model• Attack scenarios

– Identify countermeasures– Apply these countermeasures


27

CASE STUDY

the Twitter case

(because it’s simple to understand, and solved)


28

Get fast and cheap results

• Quick start: automatic security scan!!!– Runtime: 10 minutes (if you use a 9600 bps modem)

– It should reveal major holes…

*: 7Safe - UK Security breach investigations report 2010Antonio Fontes / Confoo Conference, Montreal / 2010

Reducing the heatmap

A1: Injection A2: Cross Site Scripting (XSS)

A3: Broken Authentication

and Session Management

A4: Insecure Direct Object References

A5: Cross Site Request Forgery

(CSRF)

A6: Security Misconfiguration

A7: Failure to Restrict URL Access

A8: Unvalidated Redirects and

Forwards

A9: Insecure Cryptographic

Storage

A10: Insufficient Transport Layer

Protection

30

Major use cases


Code Use case

UC-AUTH User authenticates

UC-UPD-WEB User updates his/her status from the web application

UC-UPD-SMS User updates his/her from a mobile phone (SMS message)

UC-ADD-LIST User adds someone to his/her follow-list

UC-WATCH-USER User browses another user’s status feed

UC-WATCH-FOLLOWERS User browses another user’s follow list

31

Valuable assets


Asset Description

Accounts Represent someone in the real world

Credentials Passwords, authenticate users

Mobile phone numbers Property of user

Status messages All activities the user reported in the application

Follow-list The users an user is following

Data-flows

Web Server

Authenticate

User

Messages & lists

Log & Audit

Requests

Accounts and credentials

Set status

View archive

View user feed

consumes

uses

Register

SMS gateway Mobile numbers

Data stores: any need for encryption?

Data transport in semi-trust zone: any need for encryption?

Data transport in non-trust zone: any need for encryption?

Trust boundary: what is the input validation strategy?

Factors: what credentials make a valid authentication? Can they be spoofed?

33

Nightmares list (think “STRIDE”)


Code STRIDE Asset Nightmare

N-1 I Accounts Someone gets access to all emails

N-2 S,I Credentials Someone gets access to all passwords

N-3 S,I Accounts-credentials Someone guesses a critical user password

N-4 S,I Credentials Someone intercepts a password

N-5 I Mobile phone numbers Someone gets access to users phone number

N-6 S Mobile phone numbers Someone spoofs another user phone number

N-7 T Status messages Someone destroys them all

N-8 S,T,R,D,E Status messages Someone inserts a status message on someone else’s account

N-9 S,T,R,I,D,E Status messages Someone inserts an attack payload as a message

N-10 T Follow-list A user’s follow list is modified

Etc. - - -

34

Countermeasures


Nightmare N-3

Scenario Someone guesses a critical user account password

STRIDE code(s) S,I

Countermeasure(s) Require complex passwords

Risks Compliance: -Reputation: -Privacy: -

Remarks -

Complexity estimate Easy

35

Countermeasures


Nightmare N-6

Scenario Someone spoofs another user phone

STRIDE code(s) S,I

Countermeasure(s) Prepend message with a personal PIN code


Remarks PIN has credential status -> protect!

Complexity estimate Easy

36

Countermeasures


Nightmare N-8

Scenario Someone inserts a message on someone else’s account(typically, CSRF attack…?)

STRIDE code(s) S,T,R,D,E

Countermeasure(s) Use anti-csrf techniques in the status update form


Remarks -

Complexity estimate Moderate to Complex

37

CASE STUDY

is this already useful?


38

April 2007

• A security vulnerability was reported on April 7 2007 by Nitesh Dhanjani & Rujith.

• The problem was due to Twitter’s using the SMS message originator as the authentication of the user’s account.

• Nitesh used fakemytext.com to spoof a text message.• This vulnerability can only be used if the victim’s phone

number is known. • Twitter introduced an optional PIN that its users can

specify to authenticate SMS-originating messages within a few weeks of this discovery

• http://en.wikipedia.org/wiki/Twitter


http://en.wikipedia.org/wiki/Twitter

39

2008

• BrainShaler.com, 2008, writes a blog entry where his Twitter account gets hacked by a friend.

• After tarnishing his online reputation, his friend was persuaded to give back the account and he managed to change his password.

• However, this did not seem to help. • His friend still had access because his friend was

already authenticated. • Twitter’s sessions did not expire, therefore, access was

granted as long as his friend had an active session and didn’t log out

• http://en.wikipedia.org/wiki/Twitter



40

January 2009• 33 high-profile Twitter accounts were compromised, and

falsified messages—including sexually explicit and drug-related messages—were sent.

• The accounts were compromised after a Twitter administrator’s password was guessed via a dictionary attack.

• We are engaged in a full security review of all access points to Twitter. In the meantime, we are taking immediate action. First, we are increasing the security of our sign-in mechanism. For added security, we are further restricting access to our support tools.

• http://en.wikipedia.org/wiki/Twitter http://blog.twitter.com/2009/01/monday-morning-madness.html



http://blog.twitter.com/2009/01/monday-morning-madness.html

41

It seems to help…


42

what’s next?


43

#1: Clean up!• Configure your bug tracking tool:

• Add a ‘security’ category• Add a “critical, high, low” impact attribute• Add a “design, implementation, configuration” source attribute• Don’t forget to store the time required to fix the issue!

– At later time, this will help you get $$$!

• Start testing your web application:• Automated if you don’t have time.• OWASP Application Security Verification Standard is a good start

http://www.owasp.org/index.php/ASVS

• Identify your worst nightmares• Conduct lazy threat analysis and check if countermeasures are in place

• Fix all security issues you find:• WARNING: Don’t find problems if you’re not ready to solve them!• After this point, you will already be ahead of many others.


http://www.owasp.org/index.php/ASVS

44

#2: Sharpen your skills!

• Understand technical attacks and countermeasures:– Threat classification (WASC)

http://projects.webappsec.org/Threat-Classification – Top 10 Web application security risks (OWASP)

http://www.owasp.org/index.php/Top_10

• Learn and adhere to secure coding principles:– Secure Development Principles Whitepaper (Security Ninja)

http://www.securityninja.co.uk/wp-content/uploads/2009/09/secure_development_principles_final.pdf

• Learn threat modeling:– Theat Modeling Web Applications (Microsoft)

http://msdn.microsoft.com/en-us/library/ms978516.aspx

• Evangelize around you:– Show and share with your teammates what you learned!


http://projects.webappsec.org/Threat-Classification

http://www.owasp.org/index.php/Top_10



http://msdn.microsoft.com/en-us/library/ms978516.aspx

45

#3: Talk to management!

• Be ready to hit walls– Otherwise, stay silent and just fix what you can.

• Compile your data– C-levels understand “financial profit”, “compliance”,

and “reputation exposure”:• Tell them what is the current situation• Look into your bug tracking tool: how much time was (or

will be) involved into fixing the flaws you found? How much time would it take fixing them at design time?

• Get promoted (and ask for a raise, if you date)

– “Product Manager – Security & Privacy”


46

#4: Continue securing your SDLC

• Choose your college:• Security Development Lifecycle (Microsoft)

http://blogs.msdn.com/sdl/ • Open Software Assurance Maturity Model (OWASP)

http://www.opensamm.org/ • Building Security in Maturity Model (Cigital/Fortify)

http://www.bsi-mm.com/



http://blogs.msdn.com/sdl/

http://www.opensamm.org/

http://www.bsi-mm.com/

47

Conclusion

What’s the 1st major wall? Just start.


48

Conclusion

What’s the 2nd major wall? Not applying those damn

checklists.


49

Conclusion

If you can “start” and “apply a checklist”…You’re almost done! ;)


50

questions…?


51

Thank you!Antonio Fontes / Confoo Conference, Montreal / 2010

• [email protected]• t:starbuck3000• slideshare: starbuck3000

next

• Google:“list of (free) web application security scanners”

• Find checklists:– Google:”web application security checklist”– OWASP ASVS– MS web application threats and countermeasures

security checklist• Start fixing!

53

Copyright

• You are free:– To share (copy, distribute, transmit)– To remix

• But only if: – You attribute this work– You use it for non-commercial purposes– And you keep sharing your result the

same way I did


Technology

Web application security: how to start?