A three-for-one of short talks on Web Application Security. First, are you secure? What is secure anyway? How can you be sure? Wouldn't it be nice if there was some kind of checklist you could show when someone asks you these questions? Fortunately several security specialists at the Open Web Application Security Project (OWASP) thought so too and created just such a list, called Application Security Verification Standard (ASVS). We'll look at what it is and how you can use it. Next we will discuss the Dutch Meldplicht Datalekken that came into effect on the first of January this year and what it means for you as a software developer. Finally we'll wrap up with a quick overview of the OWASP Top 10 and less obvious vulnerabilities that might be lurking in your codebases. https://www.meetup.com/Code-by-the-sea/events/234264535/

2. Boy Baukema
Security Specialist @
Ibuildings.nl

3. Security what?
• Senior Engineer
+ interest in WebAppSec
+ 4 hours a week R&D
+ internal training & consultancy
+ internal & external auditing

4. – Ibuildings CTO
“Make security something I can sell,
give managers a knob to turn.”

6. Application
Security
Verification
Standard

7. Level 1 Level 2 Level 3
1.1 X X X
1.2 X X
2.1 X X X
2.2 X

9. • Finance and Insurance
• Manufacturing, professional, transportation,
technology, utilities, infrastructure, and defense
• Healthcare
• Retail, food, hospitality

10. V2.16
Verify that credentials are transported
using a suitable encrypted link and that
all pages/functions that require a user to
enter credentials are done so using an
encrypted link.
Level 1

11. 2.26
Verify re-authentication, step up or
adaptive authentication, two factor
authentication, or transaction signing is
required before any application-specific
sensitive operations are permitted as
per the risk profile of the application.
Level 2

12. 8.12
Verify that the logs are stored on
a different partition than the
application is running with proper
log rotation.
Level 3

18. IANAL

19. http://www.nu.nl/internet/4322459/bijna-helft-van-
nederlandse-gemeenten-meldde-jaar-datalek.html

20. Data leak notification
requirement
• A vulnerability !== a leak
• Leaks must be reported within 72 hours
• Failure to report may result in fine up to EUR
820.000
(UPDATE: €20.000.000 or 4% of worldwide
revenues)

21. Which data?
• Personal data:
• Credentials
• Financial
• Identifying (identity theft risk)
• Stigmatizing or sensitive
(religion, sexual preference, etc.)

22. Examples data leak
• Logs
• Stolen laptop / USB stick
• rm -rvf / (without backup)
• Malware infection
• Printing users[0] on frontpage

23. Examples data leak
• Shoulder surfing in train while in customer backend
• Third party developer accessed customer data
• Data centre fire
• Mailing with CC instead of BCC

26. A1 - Injection
• Content
• SQL / DQL
• XML (XXE)
• URL
• Command / Shell
• LDAP
• Memcached
• Solr
• AngularJS
• Redis

27. Content / URL
• http://www.rtlnieuws.nl/node/1842021/nos-is-beter
• http://vulnerablesite/suggestions.php?
stockid=123&stockrecommendation=We+Really
+Recommend+You+Sell+This+Stock+Now

28. XXE
<?xml version="1.0"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd"
>]><foo>&xxe;</foo>

29. Memcached

30. Memcached

31. Solr
http://host:port/solr/core/update?
stream.body=<delete><query>*:*</query></
delete>&commit=true
{! rows=5000000}

32. AngularJS
• {{constructor.constructor('alert(1)')()}}

33. Redis
The Redis protocol has no concept of string
escaping, so injection is impossible under normal
circumstances using a normal client library. The
protocol uses prefixed-length strings and is
completely binary safe.

34. A2 - Broken Auth & Sess
• Credentials over HTTP
• Brute forceable credentials
• Session fixation
• Infinite Session length

35. A3 - XSS
• How do you encode plain text from JavaScript?
• Why do we even care about this with browser XSS
detection?
• How does Content-Security-Policy help?

36. A4 - Direct Object Refs

37. Session Fixation
• ?PHPSESSID=abc123

38. JSON Web Token

39. A5 - Security Misconfig
• Is any of your software out of date? This includes the OS, Web/App
Server, DBMS, applications, and all code libraries (see new A9).
• Are any unnecessary features enabled or installed (e.g., ports,
services, pages, accounts, privileges)?
• Are default accounts and their passwords still enabled and
unchanged?
• Does your error handling reveal stack traces or other overly
informative error messages to users?
• Are the security settings in your development frameworks (e.g.,
PHP.ini, Drupal, Symfony, etc) and libraries not set to secure
values?

40. A6 - Sensitive Data
Exposure
• Is any of this data stored in clear text long term, including
backups of this data?
• Is any of this data transmitted in clear text, internally or
externally? Internet traffic is especially dangerous.
• Are any old / weak cryptographic algorithms used?
• Are weak crypto keys generated, or is proper key
management or rotation missing?
• Are any browser security directives or headers missing
when sensitive data is provided by / sent to the browser?

42. A8 - Cross Site Request
Forgery

43. https://security.linkedin.com/blog-archive#11232015
Clickjacking LinkedIn

44. A9 - Using Known
Vulnerable Components

45. A10 - Unvalidated Redirects
& Forwards
• https://slack.com/checkcookie
?redir=http://www.likelo.com
• https://www.wepay.com/v2/oauth2/authorize
?client_id=112736
&redirect_uri=http://www.maliciousurl.com
&scope=send_money
• window.opener