web

Security

for developers

Basics

There is no perfect security

Anything can be hacked

Given enough commitment and time

 

But you can make it economically unviable

Economy

What data do you have?

What is it worth?

To whom?
 

Competitors, Criminals, Reporters...

Risc Analysis

  • Data sources
  • Systems
  • Economic worth (for third parties)
  • Cost in case of breach

 

Cost to hack > Economic worth


Cost to safeguard < Cost of breach

Security MEasures

  • Preventive
  • Detection
  • Mitigation
  • Recovery

Preventive

  • Development
  • Testing

Development

  • Security awareness by developers
  • Knowledgebase anchored in organization
  • Automated quality control
  • Follow security updates for 3rd party code
  • Simplify - Small Attack Surface

"Developers must be right every time,

a hacker only has to be right once"

Build safety nets for developers.

 

Code > Configuration > Procedures > Knowledge

testing

  • Code quality analysis
  • Regression testing
  • Fuzzing
  • Red team

detection

  • Clean error logs
  • Intrusion Detection
  • Network Monitoring
  • Honey Traps

mitigation

  • Layers
  • Encryption
  • Isolation / partition (systems and accounts)

recovery

  • Kill switch?
  • Disclosure?
  • Long term backups, signed, off-site
  • Rebuild from known good sources

owasp top 10

https://www.owasp.org/images/7/72/OWASP_Top_10-2017_(en).pdf.pdf

  1. Injection
  2. Broken Authentication
  3. Sensitive Data Exposure
  4. XML External Entities (XXE)
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross-Site Scripting (XSS)
  8. Insecure Deserialization
  9. Components with Known Vulnerabilities
  10. Insufficient Logging & Monitoring

Weird machine

  • credit data of 150 million americans exposed
  • security office of more than 200 people

Equifax: a case study

exploit

  • File Upload with special Content-Type

Apache Struts

  • Popular Java framework
  • In use since before 2004
  • Security patch available for months
  • Exploits known for months (CVE-2017-5638)

Details

- return LocalizedTextUtil.findText(this.getClass(), errorKey, defaultLocale, 
e.getMessage(), args);
+ if (LocalizedTextUtil.findText(this.getClass(), errorKey, defaultLocale, null, new Object[0]) == null) {
+     return LocalizedTextUtil.findText(this.getClass(), "struts.messages.error.uploading", 
defaultLocale, null, new Object[] { e.getMessage() });
+ } else {
+     return LocalizedTextUtil.findText(this.getClass(), errorKey, defaultLocale, null, args);
+ }
https://github.com/apache/struts/commit/352306493971e7d5a756d61780d57a76eb1f519a

 

defaultMessage:
e.getMessage() vervangen door null

OGNL

Object Graph Notation Language

@param defaultMessage the message to be returned 
if no text message can be found in any resource bundle

 

If not found, look for message in child property.  This is determined by evaluating the message key as an OGNL expression.  For example, if the key is user.address.state, then it will attempt to see if "user" can be resolved into an object.  If so, repeat the entire process from the beginning with the object's class as aClass and "address.state" as the message key.

findText(Class aClass, String aTextName, Locale locale, 
    String defaultMessage, Object[] args)

https://github.com/apache/struts/blob/master/core/src/main/java/com/opensymphony/xwork2/util/StrutsLocalizedTextProvider.java

"weird machine"

https://news.ycombinator.com/item?id=5512326

https://www.youtube.com/watch?v=3kEfedtQVOY

 

Hard-to-parse protocols require complex parsers. Complex, buggy
    parsers become weird machines for exploits to run on. Help stop weird
    machines today: Make your protocol context-free or regular!
Protocols and file formats that are Turing-complete input languages
    are the worst offenders, because for them, recognizing valid or
    expected inputs is UNDECIDABLE: no amount of programming or testing
    will get it right.
A Turing-complete input language destroys security for generations of
    users.  Avoid Turing-complete input languages!

related: the rule of least power

recommendations

-    Understand which supporting frameworks and libraries are used in your software products and in which versions. Keep track of security announcements.


-    Establish a process to quickly roll out a security fix release of your software. Best is to think in terms of hours or a few days, not weeks or months.
 

-    Any complex software contains flaws. Don't build your security policy on the assumption that supporting software products are flawless, especially in terms of security vulnerabilities.
 

-    Establish security layers. It is good software engineering practice to have individually secured layers behind a public-facing presentation layer such as the Apache Struts framework.
 

-    Establish monitoring for unusual access patterns to your public Web resources.

Made with Slides.com