Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Web Application Security Training v4.1.0


Published on

The 2-day "Web Application Security Training" covers the following goals:

* Build security awareness for web applications
* Get to know attack methods of hackers
* Learn ways to discover security vulnerabilities
* Learn the basics of secure web development

The training starts with a motivation of the topic and then dives head-first into the most severe vulnerabilities of web applications based on the OWASP Top 10 list. The attacks on those vulnerabilities are discussed and can be tried out by the students in the intentionally insecure web application OWASP Juice Shop. For each vulnerability possible countermeasures and mitigations are discussed after the practical hacking session.

Published in: Technology
  • Be the first to comment

Web Application Security Training v4.1.0

  1. 1. v4.1.0 (27.03.2018) Björn KimminichörnKimminich
  2. 2. Build security awareness for web applications Get to know attack methods of hackers Learn to discover security vulnerabilities Try out practical exploits in several exercises Learn the basics of secure web development
  3. 3. Schedule •2x8 hours •Breaks on demand •Excercises will be tailored for the group Behavior •No daily work during workshop •Ask questions immediately •Open discussion encouraged
  4. 4. Motivation Open Web Application Security Project (OWASP) Top 10 Web Application Security Risks (A1-A5)
  5. 5. Top 10 Web Application Security Risks (A6-A10) Secure Software Development Lifecycle Quiz & Wrap-Up
  6. 6. A weakness of an asset or group of assets that can be exploited by one or more threats (ISO 27005) A flaw or weakness in system security procedures, design, implementation, or internal controls that could […] result in a security breach or a violation of the system's security policy (NIST SP 800-30) A zero-day vulnerability is […] unknown to those who would be interested in mitigating the vulnerability (including the vendor of the target software) Source: and
  7. 7. A piece of software, a chunk of data, or a sequence of commands that takes advantage of a bug or vulnerability to cause unintended or unanticipated behavior to occur on computer software, hardware, or something electronic (usually computerized) An exploit directed at a zero-day vulnerability is called a zero-day exploit, or zero-day attack. Source: and
  8. 8. Script Kiddies Playing around, bragging rights & wreaking havoc Hacktivists Loose groups with (pseudo-)politically motivation Organized Crime Gangs Monetization, 9-to-5 jobs, Cyber-Crime-as-a-Service Corrupt / Disgruntled Employees Painful and very hard to protect against Competitors Interested in business secrets, contracts, … Nation States Unlimited resources and budget = Game Over!
  9. 9. Attacker must succeed once Defender must get it right all the time Attacker can choose the weakest spot Defender must defend all places Attacker can leverage zero-days Defender can only defend against known attacks Attacker can play dirty Defender needs to play by the rules
  10. 10. Source:
  11. 11. Source:
  12. 12. Source:
  13. 13. Source:
  14. 14. Source:
  15. 15. Source:
  16. 16. Source:
  17. 17. Visit Type in your email address Hit the „pwned?“ button Green or red for you?  Source:
  18. 18. Do you know… …your CIO? …your CISO? …your CIRT? …any other teams working in security?
  19. 19. Open Web Application Security Project
  20. 20. Open Web Application Security Project Free and open software security community 501(c)(3) Nonprofit organization Core purpose Be the thriving global community that drives visibility and evolution in the safety and security of the world’s software Source:
  21. 21. OPEN Everything at OWASP is radically transparent from our finances to our code. INNOVATION OWASP encourages and supports innovation and experiments for solutions to software security challenges. GLOBAL Anyone around the world is encouraged to participate in the OWASP community. INTEGRITY OWASP is an honest and truthful, vendor neutral, global community. Source:
  22. 22. Top 10 Web Application Security Risks
  23. 23. Source: Ex-A6/2007: Information Leakage and Improper Error Handling A1: Injection A2: Broken Authentication A3: Sensitive Data Exposure A4: XML External Entities A5: Broken Access Control A6: Security Misconfiguration A7: Cross-Site-Scripting (XSS) A8: Insecure Deserialization A9: Using Comp. with Known Vulnerabilities A10: Insufficient Logging & Monitoring
  24. 24. Source:
  25. 25. OWASP Top 10 Cross-Site Request Forgery (CSRF) Uncontrolled Resource Consumption ('Resource Exhaustion', 'AppDoS') Unrestricted Upload of File with Dangerous Type User Interface (UI) Misrepresentation of Critical Information (Clickjacking etc.) Unvalidated Forward and Redirects Improper Control of Interaction Frequency (Anti-Automation) Inclusion of Functionality from Untrusted Control Sphere (3rd Party Content) Server-Side Request Forgery (SSRF) … ? Source:
  26. 26. Vulnerable Target Practice Application
  27. 27. Use only a local instance for the exercises! Do not attack the demos deployed on Heroku (https://juice-shop(-staging)
  28. 28. 1. Install node.js from 2. Install the application using either of Fork: Clone: git clone Unzip: 3. Run npm install (skip for unzipped release archives) 4. Run npm start 5. Browse to http://localhost:3000 Alternatively use Heroku, Docker or Vagrant!
  29. 29. Google Chrome Chrome DevTools PostMan (App) cURL Mozilla Firefox Firefox DevTools The Firefox DevTools have an Edit & Resend feature for HTTP requests built in! Crafting HTTP requests from scratch is something PostMan is very convenient for!
  30. 30. Do not look at the source code Do not look at the server log Do not browse (except for the Feel free to perform Internet research! Some exercises might even require to follow trails through the Internet! We‘ll do some hacks together, the rest you‘ll do on your own At the end of the training we will not have solved 100% of the challenges on the Score Board! Feel free to fill the gaps as a homework… 
  31. 31. If you are to shy to ask the trainer for help… …you can find hints for each exercise in the Official Companion Guide eBook Published (for free) on LeanPub and GitBook and readable online at:
  32. 32. Do not perform any attacks on servers, networks and applications… …you do not own and operate yourself …or have the owners permission to pentest This includes „your own“ cloud-hosted apps
  33. 33. Prevalence Widespread Impact Minor
  34. 34. Applications can unintentionally leak information about their configuration or internal workings, or violate privacy internal state via how long they take to process certain operations or via different responses to differing inputs information about their internal state through detailed or debug error messages This information can be leveraged to launch or even automate more powerful attacks Source:
  35. 35. Implementation Details Server (OS, Version, …) Programming Language (Language, Version, VM-Vendor, …) Database (Oracle, mySQL, …) and details about it (Version, Schema Names, Table Names, Column Names, …) Names and versions of used 3rd party libraries Other useful information Stacktraces Debugging Information SQL Statements Passwords … Source:
  36. 36. vs.
  37. 37. vs. while (noSuchUserError) { // try next user with static password login(user, „?“); } while (wrongPasswordError) { // use existing user and try next password login(„bkimminich“, password); } while (loginFailedError) { // try next user while (loginFailedError) { // try next password login(user, password); } }
  38. 38. Task 1: Find the hidden „Score Board“ page Task 2: Try to provoke some error messages What information – if any – is leaked on those? Did you actually see the error occuring? If not, where else might you look for it? 3.1.1 3.1.2
  39. 39. Common approach to exception handling Disable or limit detailed error messages Ensure that secure paths that have multiple outcomes return similar or identical error messages in roughly the same time Create a default error handler which returns an appropriately sanitized error message for most users in production for all error paths
  40. 40. Configure a generic error page in your web.xml Instead of relying on the server‘s default page which often contains information leakage
  41. 41. Exploitability Easy Prevalence Common Detectability Easy Impact Severe
  42. 42. Injection means… …tricking an application into including unintended commands in the data sent to an interpreter Interpreters… …take strings and interpret them as commands SQL, OS Shell, LDAP, XPath, Hibernate, etc… Source:
  43. 43. Source: Unintended Command Interpreter
  44. 44. SELECT user_id FROM user_data WHERE user_name = 'bkimminich' AND user_password = '680e89[…]75ab'; // … String query = "SELECT user_id FROM user_data WHERE " + user_name = '" + req.getParameter("user") + "' AND user_password = '" + req.getParameter("password") +"'"; // …
  45. 45. SELECT user_id FROM user_data WHERE user_name = '' or 1=1 --' AND user_password = '1234'; // … String query = "SELECT user_id FROM user_data WHERE " + user_name = '" + req.getParameter("user") + "' AND user_password = '" + req.getParameter("password") +"'"; // …
  46. 46. Typical Impact Spy out or manipulate data Manipulate the DB server or access underlying OS Bypass authentication or gain admin privileges Correlation with Information Leakage Attackers use error messages or codes to verify the success of an attack and gather information about type and structure of the database Blind SQL Injection If error message don’t help the attacker he can still “take a stab in the dark” The normal application behavior (e.g. response time) might give away clues on successful/failed Injection attempts Source:
  47. 47. Bypass Authentication admin' -- admin' # admin'/* ' or 1=1-- ' or 1=1# ' or 1=1/* ') or '1'='1 ') or ('1'='1 Source:
  48. 48. Spy out Data ' UNION SELECT login, password, 'x' FROM user-- 1 UNION SELECT 1,1,1 FROM user-- Manipulate Data '; UPDATE user SET type = 'admin' WHERE id = 23;-- Manipulate the DB Server ' ;GO EXEC cmdshell('format C') -- Cheat Sheet Source:
  49. 49. Source:
  50. 50. Task 1: Log in as an existing user Do not use password guessing Do not use brute forcing Task 2: Order the Christmas special offer that was only avaiable in 2014 Task 3: Read all user account ids, emails and passwords from the database 3.1.3
  51. 51. Plain SQL via JDBC HQL via Hibernate String query = "SELECT account_balance FROM user_data WHERE user_name = " + request.getParameter("customerName"); try { Statement statement = connection.createStatement(…); ResultSet results = statement.executeQuery(query); } Query unsafeHQLQuery = session.createQuery("from Inventory where productID='"+userSuppliedParameter+"'");
  52. 52. Avoid the Interpreter at all if possible Use an interface that supports bind variables java.sql.PreparedStatement Hibernate Parameter Binding … Enforce Least Privileges for the application‘s DB user Perform White List Input Validation on all user supplied input Source:
  53. 53. White List = Positive Security Rule „Block what is not explicitly allowed!“ Example: Allow only [a-z], [A-Z] and [0-9] Define once, (almost) never worry again Can be quite effortsome to define for a whole application Black List = Negative Security Rule „Allow what is not explicitly blocked!“ Example vs. SQL Injection: Block [-#';] Example vs. HTML Injection: Block [<>";'script] Can be bypassed by masking attack patterns Must be updated for new attack patterns
  54. 54. Plain SQL via JDBC HQL via Hibernate String customerName = request.getParameter("customerName"); assert(CustomerValidator.doesExist(customerName); String query = "SELECT account_balance FROM user_data WHERE user_name = ?"; PreparedStatement pstmt = connection.prepareStatement(query); pstmt.setString(1, customerName); ResultSet results = pstmt.executeQuery(); Query safeHQLQuery = session.createQuery("from Inventory where productID=:productId"); safeHQLQuery.setParameter("productId", userSuppliedParameter);
  55. 55. Intention: Provide cheap means of DB/data maintenance to admin users Protection: URL is hidden Never develop like this!
  56. 56. Exploitability Easy Prevalence Common Detectability Average Impact Severe
  57. 57. Source:
  58. 58. HTTP is a “stateless” protocol Credentials have to be passed with every request Should use SSL for everything requiring authentication Session Management flaws SESSION ID is just as good as credentials to an attacker SESSION ID is typically exposed on the network, in browser, in logs, … Beware the side-doors Change my password, remember my password, forgot my password, secret question, logout, email address, credentials stored in plain text in database, etc… Typical Impact User accounts compromised or user sessions hijacked Source:
  59. 59. h5kek4z9ha1rtrf gj75l3k7hb15rtr l8l65k45hc1rw7i p05jrj53hd1i039 5urltda1he1bn46 j5le97h9hf2yq3h po953ld7hg2awi9 t6zhj2n5hh27bn0 iu345r53hi2aw34 o0z43411hj2njkl 9por42o9hk3dfrz … • 9,7,5,3,1,9,7,5,3,1,9… • h,h,h,h,h,h,h,h,h,h,h,… • a,b,c,d,e,f,g,h,i,j,k,… • 1,1,1,1,1,2,2,2,2,2,3,… Pattern
  60. 60. Authentication should be simple, centralized and standardized! Use standard session ID of your container Protect credentials and session ID with SSL/TLS Keep your SSL certificate safe Automatic logout of inactive sessions Never start a login process from an unencrypted page Session IDs and credentials don’t belong into logfiles Source:
  61. 61. Source: Rely on single authentication mechanism with appropriate strength and number of factors Use strong supplemental authentication mechanisms Challenge-Response Limited time passwords Check old password on password change Send confirmation request to old email address on email address change
  62. 62. Task 1: Log in with the admin‘s user account Task 2: Log in with Jim‘s user account Do not use SQL Injection 3.1.10
  63. 63. AttackVector Average Prevalence Widespread Detectability Average Impact Severe
  64. 64. Storing sensitive data insecurely Failure to identify all sensitive data Failure to identify all the places that this sensitive data gets sent or stored On the web, to business partners, internal communication Databases, files, directories, log files, backups, etc. Failure to properly protect this data in every location Source:
  65. 65. Typical Impact Attackers access or modify confidential or private information (e.g credit cards, health care records, financial data, …) Attackers extract secrets to use in additional attacks Company embarrassment, customer dissatisfaction, and loss of trust Expense of cleaning up the incident, such as forensics, sending apology letters, reissuing thousands of credit cards, providing identity theft insurance Business gets sued and/or fined Source:
  66. 66. Sensitive Data is not encrypted Using self-made crypto algorithms Unsafe usage of safe crypto algorithms Store Keys and Passwords in Source Code Store Keys/Certificates in unsafe location Continued usage of weak crypto algorithms e.g. MD5, SHA-1, RC3, RC4
  67. 67. 3.1.5 3.1.10 Task 1: Access a confidential document Task 2: Log in with Bjoern‘s user account Do not previously change the password apply SQL Injection hack Bjoern‘s Google account 
  68. 68. Verify your architecture Identify all sensitive data Identify all the places that data is stored Ensure threat model accounts for possible attacks Use encryption to counter the threats, don’t just ‘encrypt’ the data Protect with appropriate mechanisms File encryption, database encryption, data element encryption Use TLS on all connections with sensitive data Use the mechanisms correctly Use standard strong algorithms e.g. AES, RSA, SHA-256 Generate, distribute, and protect keys properly Be prepared for key change Verify the implementationSource:
  69. 69. Be especially careful in unknown Networks WLAN Hotspots, Internet Cafés, … Source:
  70. 70. AttackVector Average Prevalence Common Detectability Easy Impact Severe
  71. 71. In the DTD you specify shortcuts as ENTITY… <!ENTITY author "Björn Kimminich"> <!ENTITY copyright "(C) 2018"> …to later dereference them in the XML <author>&author; &copyright;</author> Source:
  72. 72. DTD changed to use External Entities… <!ENTITY author SYSTEM ""> <!ENTITY copyright SYSTEM"> …whereas the XML stays the same <author>&author; &copyright;</author> Source:
  73. 73. Many older or poorly configured XML processors evaluate external entity references within XML documents External entities can be used for disclosure of internal files internal port scanning remote code execution denial of service attacks Source:
  74. 74. Extracting Data Network Probing DoS Attack <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo> <!ENTITY xxe SYSTEM "" >]> <!ENTITY xxe SYSTEM "file:///dev/random" >]> Source:
  75. 75. Task 1: Identify the weak point of the application that accepts arbitrary XML data Task 2: Retrieve the content of your local system‘s C:Windowssystem.ini or /etc/passwd via an XEE attack 3.1.5 3.1.14
  76. 76. Configure XML parser to… …disable DTDs completely (by disallowing DOCTYPE declarations) …disable External Entities (only if allowing DTDs cannot be avoided) Selective validation or escaping of tainted data is not sufficient, as the whole XML document is crafted by the attacker Source:
  77. 77. AttackVector Average Prevalence Common Detectability Average Impact Severe
  78. 78. Restrictions on what authenticated users are allowed to do are often not properly enforced Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts view sensitive files modify other users’ data change access rights etc. Source:
  79. 79. Modifying URL, internal application state, or HTML page Changing the primary key to another users record Elevation of privilege Acting as a user without being logged in Acting as an admin when logged in as a user. Metadata manipulation replaying or tampering with access control tokens cookie or hidden field manipulation Force browsing to authenticated pages as an anonymous user or to privileged pages as a standard user Accessing API with missing access controls for POST, PUT and DELETE Source:
  80. 80. Checking online how you did in an exam http://universi.ty/marks?id=i99a19 Checking how your fellow students did http://universi.ty/marks?id=i99a01 http://universi.ty/marks?id=i99a02 … Checking the distribution among class http://universi.ty/marks?id=i99 Probably the worst thing that can happen http://universi.ty/marks?id=i99a19&mode=edit
  81. 81. Task 1: Access another user‘s basket Task 2: Post some feedback for another user without logging in as that user Task 3: Place an order with a negative total Task 4: Access one or more misplaced files Includes „A3 – Sensitive Data Exposure“ sub- exercise! 3.1.9 3.1.5 3.1.4
  82. 82. Access control is only effective if enforced in trusted server-side code With the exception of public resources, deny by default Implement access control mechanisms once and re-use them throughout the application Enforce record ownership Disable web server directory listing and ensure file metadata and backup files are not present within web roots Log access control failures, alert admins when appropriate Rate limit API and controller access to minimize the harm from automated attack tooling Access tokens should be invalidated on the server after logout Developers and QA staff should include functional access control unit and integration tests Source:
  83. 83. See you all tomorrow!
  84. 84. Task 1: Access the administration section of the store Task 2: Get rid of all ***** rated Feedback Task 3: Change the link in the O-Saft product description into 3.1.4
  85. 85. Björn KimminichörnKimminich
  86. 86. Let‘s see what you remember…
  87. 87. Top 10 Web Application Security Risks (A6-A10) Secure Software Development Lifecycle Quiz & Wrap-Up
  88. 88. AttackVector Easy Prevalence Widespread Detectability Easy Impact Moderate
  89. 89. Web applications rely on a secure foundation Everywhere from the OS up through the App Server Don’t forget all the libraries you are using! Is your source code a secret? Think of all the places your source code goes Security should not require secret source code Do you change all credentials regularly in your production environment? Source:
  90. 90. Install backdoor through missing OS or server patch XSS flaw exploits due to missing application framework patches Unauthorized access to default accounts, application functionality or data, or unused but accessible functionality due to poor server configuration Source:
  91. 91. Source: Hardened OS Web Server App Server Framework App Configuration Custom Code Accounts Finance Administration Transactions Communication KnowledgeMgmt E-Commerce Bus.Functions Test Servers QA Servers Source Control Development Database Insider
  92. 92. Verify your system’s configuration management Secure configuration “hardening” guideline Automation is really useful here Must cover entire platform and application Keep up with patches for all components This includes software libraries, not just OS and Servers! Analyze security effects of changes Deactivate unnecessary stuff Ports, Services, Accounts, Sites, … Verify the implementation Scanning finds generic configuration and missing patch problems Source:
  93. 93. Exploitability Easy Prevalence Widespread Detectability Easy Impact Moderate
  94. 94. Attacker sends malicious code to an innocent user’s browser Malicious code might be… …reflected from web input (form or hidden field, URL, etc…) …stored in database …sent directly into rich JavaScript client Virtually every web application has this problem Source:
  95. 95. Scriptlet in Java Server Page (JSP) <%String searchCriteria = request.getParameter("searchValue");%> <%-- Later on the same or subsequent JSP... --> Search results for <b><%=searchCriteria%></b>: ...
  96. 96. Steal user’s session Steal sensitive data Rewrite web page Redirect user to phishing or malware site Most Severe: Install XSS proxy which allows attacker to observe and direct all user’s behavior on vulnerable site and force user to other sites Source:
  97. 97. Source: ServerBrowser Database Web Application Bug! URL HTML Victim Request Website Server Response
  98. 98. Source: ServerBrowser Database Web Application Bug! Website Server Response HTML URL URL Subsequent Victim Request
  99. 99. Source: ServerBrowser Database Web Application URL HTML Script Code Bug! Website Script Code Server Response Bug! DOM Access
  100. 100. Simple Patterns <SCRIPT>javascript:alert('XSS');</SCRIPT> <IMG SRC=javascript:alert('XSS')> <IFRAME SRC="javascript:alert('XSS');"></IFRAME> Masked / Evasive Patterns <IMG SRC=javascript:alert(&quot;XSS&quot;)> '';!--"<XSS>=&{()} <IMG """><SCRIPT>alert("XSS")</SCRIPT>"> <IMG SRC="jav ascript:alert('XSS');"> <IMG SRC="jav ascript:alert('XSS');"> Source:
  101. 101. Masked / Evasive Patterns (continued) <DIV STYLE="background- image:00750072006C0028'006a006100760061 007300630072006900700074003a0061006c00 65007200740028.10270058.1053005300270029' 0029"> <b onmouseover=alert('Wufff!')>click me!</b> <img src="" onerror=alert(document.cookie);> … Cheat Sheet: Source:
  102. 102. Client Side Validation is always for convenience but never for security! Sometimes you can just bypass the client altogether and interact with the backend instead! Or you can just stop all outgoing HTTP requests in your browser… …and tamper the contained headers, POST data and passed parameters …after Client Side Validation took place …but before they are actually submitted to the server
  103. 103. Task 1: Reflect an XSS attack back at the user Task 2: Store at least one XSS attack to the DB Visit the attacked page afterwards to verify success If you come across a seemingly sophisticated protection mechanisms it is not shameful to give up… for now… 3.1.6
  104. 104. Eliminate XSS Don‘t include user supplied input in your output! Defend against XSS Output Encode all user supplied input OWASP Java Encoder For GWT: Perform White List Input Validation on user input Use an HTML Sanitizer for larger user supplied HTML chunks OWASP Java HTML Sanitizer Source:
  105. 105. OWASP Java Encoder <%String searchCriteria = request.getParameter("searchValue");%> <%-- Later on the same or subsequent JSP... --> Search results for <b><%=Encoder.forHtml(searchCriteria)%></b>: ...
  106. 106. Presentation User Interface Business Web Service Database File SystemUser IntegrationSet Character Set Encode For HTML Global Validate Canonicalize Specific Validate Sanitize Canonicalize Validate Source:
  107. 107. Sources: HTML Style Property Values (e.g., .pdiv a:hover {color: red; text-decoration: underline} ) JavaScript Data (e.g., <script> some javascript </script> ) HTML Attribute Values (e.g., <input name='person' type='TEXT' value='defaultValue'> ) HTML Element Content (e.g., <div> some text to display </div> ) URI Attribute Values (e.g., <a href="javascript:toggle('lesson')" ) #4: All non-alphanumeric < 256  HH OWASP JE: Encoder.forCssString() #3: All non-alphanumeric < 256  xHH OWASP JE: Encoder.forJavaScriptBlock() #1: ( &, <, >, " )  &entity; ( ', / )  &#xHH; OWASP Java Encoder: Encoder.forHtml() #2: All non-alphanumeric < 256  &#xHH OWASP JE: Encoder.forHtmlAttribute() #5: All non-alphanumeric < 256  %HH OWASP JE: Encoder.forUriComponent()
  108. 108. Using a simple prepackaged policy Defining a customized policy private String sanitizeHtml(String html) { PolicyFactory policy = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS) .and(Sanitizers.LINKS); return policy.sanitize(html); } private static final PolicyFactory BASIC_FORMATTING_WITH_LINKS_POLICY = new HtmlPolicyBuilder() .allowCommonInlineFormattingElements().allowCommonBlockElements() .allowAttributes("face", "color", "size", "style", "align").onElements("font") .allowAttributes("style").onElements("div", "span").allowElements("a") .allowAttributes("href").onElements("a").allowStandardUrlProtocols() .requireRelNofollowOnLinks().toFactory();
  109. 109. AttackVector Difficult Prevalence Common Detectability Easy Impact Severe
  110. 110. The most popular data formats for serializing data are JSON and XML Many programming languages offer a native capability for serializing objects with more features Source: Object Object Byte Stream Byte StreamDB File Memory Serialization Deserialization
  111. 111. RCE Insecure deserialization often leads to remote code execution, one of the most serious attacks possible Other possible attacks include replay attacks injection attacks privilege escalation DoS Source: Object Byte StreamDB File Memory Bug!
  112. 112. Potential OutOfMemoryError from huge ArrayList Creating a recursive Object graph ArrayList<Object> foo = new ArrayList<>(Integer.MAX_VALUE) Set root = new HashSet(); Set s1 = root; Set s2 = new HashSet(); for (int i = 0; i < 100; i++) { Set t1 = new HashSet(); Set t2 = new HashSet(); t1.add("foo"); // make it not equal to t2 s1.add(t1); s1.add(t2); s2.add(t1); s2.add(t2); s1 = t1; s2 = t2; } Source:
  113. 113. Task 1: Find the „NextGen“ successor to the half-heartedly deprecated XML-based B2B API Task 2: Exploit this API with a DoS-like Remote Code Exeution If the server would need >2sec to process your attack request, it is considered „DoS-like“ enough 3.1.15
  114. 114. Avoid native deserialization formats JSON/XML lessens (but not removes) the chance of custom deserialization logic being maliciously repurposed Use the Data Transfer Object (DTO) pattern Exclusive purpose is data transfer between application layers Source:
  115. 115. If serialization cannot be avoided Sign any serialized objects & only deserialize signed data Enforce strict type constraints during deserialization before object creation (Not sufficient on its own!) Isolate deserialization in low privilege environments Log deserialization exceptions and failures Restrict or monitor incoming and outgoing network connectivity from containers or servers that deserialize Monitor & alert if a user deserializes constantly Source:
  116. 116. AttackVector Average Prevalence Widespread Detectability Average Impact Moderate
  117. 117. Heartbleed OpenSSL 1.0.1 – 1.0.1f
  118. 118. Source:
  119. 119. Source:
  120. 120. Source:
  121. 121. Libraries often contain vulnerabilities Attacker identifies a weak component through scanning or manual analysis Customized exploits used to execute attack Full range of weaknesses is possible injection, broken access control, XSS, etc. Impact could be minimal, up to complete host takeover and data compromise Source:
  122. 122. Source: SpEL Injection Authentication Bypass Remote Code Execution
  123. 123. Source:
  124. 124. Task 1: Persist a successful XSS attack via the 'Contact Us' page Task 2: Inform the shop about the vulnerable library it is using Use the 'Contact Us' page and supply the exact library name the exact version 3.1.6 3.1.8
  125. 125. Identify the components and their versions you are using, including all dependencies Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up-to- date Restrict the use of unapproved components Source:
  126. 126. AttackVector Average Prevalence Widespread Detectability Difficult Impact Moderate
  127. 127. Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected Most successful attacks start with vulnerability probing Allowing such probes to continue can raise the likelihood of successful exploit to nearly 100% Source:
  128. 128. Auditable events, such as logins, failed logins, and high-value transactions are not logged Warnings and errors generate no, inadequate, or unclear log messages Logs of applications and APIs are not monitored for suspicious activity Logs are only stored locally Appropriate alerting thresholds and response escalation processes are not in place or effective Penetration testing and scans by automated tools do not trigger alerts The application is unable to detect, escalate, or alert for active attacks in real time or near real time Source:
  129. 129. Task 1: Identify a (misplaced) file that contains rule definitions for security error alerting Task 2: Download this file… …which should be trivial if you already solved Task 4 of the „A5 – Broken Authorization“ exercises 3.1.5
  130. 130. Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts held for sufficient time to allow delayed forensic analysis Ensure that logs are generated in a format that can be easily consumed by a centralized log management solution Source:
  131. 131. Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion e.g. append-only database tables or similar Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion Establish or adopt an incident response and recovery plan Source:
  132. 132. Time to earn some stickers…!
  133. 133. Secure Software Development Lifecycle
  134. 134. Analysis / Functional Design Identify (better: Reject) potentially insecure requirements Technical Design Consider Security Aspects when designing a solution Create a Threat Model of your Applications
  135. 135. Development / Realization Know and understand common vulnerabilities Know preventive measures for each vulnerability Write Clean Code (=less likely to contain a flaw) Write Unit Tests (=less likely to miss an existing flaw) Perform Security Scans on source code level Perform Code Reviews Most importantly… Never blindly trust any user input!
  136. 136. Test Perform Penetration Tests for new functionality Have a 3rd party perform regular Pentests Support Pentests with Security Scanners Operations / Maintenance Utilize a central Web Application Firewall Establish an Incident Response Process
  137. 137. Source:
  138. 138. OWASP Software Assurance Maturity Model
  139. 139. Maturity Levels for each Security Practice 0 = Unfulfilled activities 1 = Initial understanding and ad hoc provision 2 = Increased efficiency/effectvieness 3 = Comprehensive mastery Source:
  140. 140. Source:
  141. 141. Source:
  142. 142. The Foundation of any Secure Design
  143. 143. Minimize Attack Surface Area Establish Secure Defaults Principle of Least Privilege Principle of Defense in Depth Fail securely Don‘t trust Services Separation of Duties Avoid Security by Obscurity Keep Security simple Fix Security Issues correctly Source:
  144. 144. Every feature that is added to an application adds a certain amount of risk to the overall application The aim for secure development is to reduce the overall risk by reducing the attack surface area Source:
  145. 145. The “out-of-box” experience for the user should be secure It should be up to the user to reduce their security – if they are allowed Source:
  146. 146. Accounts have the least amount of privilege required to perform their business processes This encompasses user rights and resource permissions, e.g. CPU limits memory network file system Source:
  147. 147. Where one control would be reasonable, more controls that approach risks in different fashions are better In-depth-controls can make severe vulnerabilities extraordinarily difficult to exploit Source:
  148. 148. Whenever a transaction fails or code execution throws an exception it should always “fail closed” and never “fail open” Source:
  149. 149. Third party partners more than likely have differing security policies and posture Implicit trust of externally run systems is not warranted All external systems should be treated in a similar fashion Source:
  150. 150. Separation of duties is a key fraud control Administrators should not also be users of an application they are responsible for Source:
  151. 151. Security through obscurity is a weak security control, and nearly always fails when it is the only control The security of key systems should not be reliant upon keeping details hidden Source:
  152. 152. Attack surface and simplicity go hand in hand Prefer straightforward and simple code over complex and over-engineered approaches Avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler Source:
  153. 153. Once a security issue has been identified, it is important to develop a test for it, and to understand the root cause of the issue It is likely that the security issue is widespread amongst all code bases, so developing the right fix without introducing regressions is essential Source:
  154. 154. Bringing Security into Software Design
  155. 155. Repeatable Process to find all and address all threats to you application Allows you to predicably and effectively find security problems early in the development process Help to produce software that is secure by design Source: Diagram Identify Threats Mitigate Validate
  156. 156. Source:
  157. 157. OWASP Cornucopia is a mechanism in the form of a card game to assist software development teams identify security requirements in Agile, conventional and formal development processes It is language, platform and technology agnostic Source:
  158. 158. Source:
  159. 159. (Do not expect a Silver Bullet here!)
  160. 160. Comprehensible framework providing both authentication and authorization to Java applications Includes Protection against session fixation clickjacking cross site request forgery Servlet API integration Optional integration with Spring Web MVC
  161. 161. Collection of APIs used in cryptography for both the Java and the C# Offers light-weight Java API and full JCE provider Various certificate generators/processors included S/MIME, X.509, OpenPGP, … Developed and maintained in Australia
  162. 162. The SpotBugs (fka FindBugs) plugin for security audits of Java web applications 125 bug patterns Covers popular frameworks Spring-MVC, Struts, Tapestry and many more IDE and CI plugins available Eclipse, IntelliJ, Ant, Maven, Jenkins & SonarQube
  163. 163. Utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities Generates a report linking to CVE entries Findings are rated in CVSS from 0.0 to 10.0 Suppression of findings is possible Plugins for Jenkins, SonarQube, Maven & Gradle
  164. 164. ServerNetwork Security Firewall IDS IPS Web App Malicious Requests exploit vulnerabilities and compromise application
  165. 165. ServerNetwork Security Firewall IDS IPS Web App Blackbox ScannerPenetration Test Whitebox Scanner Web App Sourcecode Code Analysis Fix + Patch Application New security holes might be introduced during ongoing development and bugfixing! Vulnerabilities might be insufficiently fixed
  166. 166. ServerNetwork Security Firewall IDS IPS Web App WAF Guidelines Ruleset WhitelistBlacklist Heuristics Defines legal/ illegal Requests Rejects illegal requests Sometimes rejects legitimate requests („False Positives“) or fails to recognize illegal requests („False Negative“)
  167. 167. Event Detection Reporting Information Collection First Assessment Relevant? Second Assessment Relevant? False Positive Incident under control?ForensicAnalysis Communications Later Response Activate Crisis Team CrisisActivities ImmediateResponse Review Improve Detection Reporting User/Source Yes No Assessment Descision Operations Support No Yes No Yes Response Information Security Incident Response Team Crisis Organization No Yes
  168. 168. A1: Injection A3: Cross-Site Scripting (XSS) A2: Broken Authentication and Session Management A4: Insecure Direct Object References A8: Cross Site Request Forgery (CSRF) A5: Security Misconfiguration A6: Sensitive Data Exposure A7: Missing Function Level Action Control A9: Using Known Vulnerable Components A10: Unvalidated Redirects and Forwards Ex-A6/2007: Information Leakage and Improper Error Handling
  169. 169. Kali Linux (formerly known as Backtrack) BackBox, ArchStrike, BlackArch, Pentoo, Bugtraq, …
  170. 170. OWASP Website Juice Shop Appsec Tutorial Series Java HTML Sanitizer Dependeny Check Vulnerable Web Applications Directory
  171. 171. Follow the survery link provided via email Please provide a 1-5 rating for each category Additional feedback is highly appreciated What did you like best about the workshop? What could have been better? What didn‘t you like at all?
  172. 172. Thank you for your attention!
  173. 173. 100% =
  174. 174. The background artwork shows the self-image of villain AI Shodan from the cyberpunk-RPG video games System Shock and System Shock 2 ©1994/1999 Looking Glass Studios/Irrational Games Background image based on „Digital Shodan“ created by sephiroth- kmfdm Source: Shodan-56013493 Recolorized using Corel PSP X5, Paint.Net and IrfanView