Non-profit foundation • Chapters all across the world • Free resources, tools and trainings • OWASP Top 10 • OWASP ASVS • OWASP SAMM • OWASP ZAP • Conferences • Global AppSec • Chicago Chapter • MeetUp Link 4 https://owasp.org/
specialized silo with an organization – it is everyone’s job • The shift towards to DevOps has brought on the concept of “total ownership” of code – and that means owning your own security • Application Security teams are becoming “enablers” not “gatekeepers” To be a successful developer in today’s age, you will have to know security concepts
an attacker” • But you also have to contextualize everything and be realistic • Understand both threats and vulnerabilities • Threat Modeling • Vulnerability scanning • Combined, you understand risk 8 What are the “threats” to a bank? Who are the “threat actors”? What are possible “vulnerabilities”? What are the “controls”?
testing is an important skill: • Know how/what attackers look for • Manually test specific vulnerabilities • Manually verify findings • Scanners (SAST/DAST) don’t understand context • Don’t understand what is “allowed” or “normal” • I want to empower you to test things yourselves With great power comes great responsibility… You should only pentest things you have permission to test! Tons of free resources on the internet (or bug bounties…) 11
is based on attacks rather than the underlying security principles • Fixing security bugs in webapps is like “whack a mole” when you don’t understand the core underlying issues • Even very experienced developers and security testers mix up things like CORS, CSRF and XSS 13 By understanding why attacks work, you can learn how to defend against them
the web • Well defined protocol with accepted verbs and headers • Generally TCP over ports 80/443 • HTML • Markup language that describes to the browser how to render a page • Not a “programming language” just a format (like XML or JSON) • CSS • Style metadata associated with HTML; tells the browser how to display the HTML • Document Object Model (DOM) • The browser parses HTML and CSS into a Document Object Model (DOM) • The DOM is ultimately what gets displayed and clicked on by the end user 14 HTML CSS Document Object Model (DOM) www.example.com
have their own JS engine that executes loaded JS code • Has full read and write control of the DOM • Modern pages make heavy use of DOM manipulation with JS (e.g. animations) • Has full access to browser storage • Can access cookies • Can talk to browser APIs • E.g. webcam, microphone, location • Browser executes JS in a sandbox to limit its power 15 HTML CSS Document Object Model (DOM) www.example.com JavaScript Storage Browser APIs Cookies In the world of web, JavaScript is king
ASCII • Uses common words and verbs • HTTP is stateless • There is no concept of “state” between clients and servers • HTTP requests and responses must be completely “standalone” and include their own identifying information 16 Request Response Body Headers
be encoded for it to work properly • E.g. newline characters have very special meaning in HTTP, so you can’t just send them “as-is” Encoding != Encrypting • This is not for security at all • It is just changing data from one format to another Web apps use various types of encoding often – it’s very useful to identify and understand the common ones “Hello World!” URL Encoding %48%65%6c%6c%6f%20%57%6f%72%6c%64%21 HTML Encoding Hello W f;rld! ASCII Hex 48656c6c6f20576f726c6421 Base64 SGVsbG8gV29ybGQh Often, only the special characters are encoded: Hello+World%21 17
a stateless protocol. So cookies were invented. This has made a lot of people very angry and been widely regarded as a bad move.” (Just kidding. Sort of) 18 • HTTP is a stateless protocol. • Servers have no way of remembering or determining who they are talking to • Servers must accept every request sent to them, and decide every time whether to process it • Cookies were invented in the early 90s as a way to hack session information into HTTP • Browsers send/receive cookies in HTTP Headers and store them in a “cookie jar”, organized by domain
used to correlate a client’s state server side • Also used for tracking clients (i.e. advertising) • Browsers are extremely “helpful” and will send any matching cookies automatically with every request • Cookies have some flags to improve security: • HttpOnly – don’t let JavaScript read/write the values • Secure – never send the value over plaintext HTTP • SameSite – new flag, more on this later ☺ 19
Storage APIs that can be leveraged by JS to store information • Two main types of browser storage: • LocalStorage • Persistent and available to the entire origin • SessionStorage • Available only to the current window • While Cookies can be “protected” from JS with the HttpOnly flag set, browser storage is always available to JS • But browser storage is never automatically sent! Cookies are scoped to a domain, but only available to JS within that origin Browser storage is isolated entirely by the origin Strictly speaking, the SOP doesn’t apply to cookies and browser storage, but the origin is still the security boundary
a resource • The browsing context changes • i.e. navigate away from a page • These include cookies automatically! 21 Browsers make HTTP requests in two distinctly important ways Some happen automatically when a page loads: Some require an event, like a user clicking: The user sees this happen – the page will change I call these “HTML requests” – they are usually triggered through HTML elements
the browser API XMLHttpRequest • Or the “fetch” API on newer browsers • JavaScript can make requests and read responses silently in the background, without the user’s interaction • Used in AJAX Programming • Asynchronous JavaScript and XML • Update the page without having to request a new one! 22 Browsers make HTTP requests in two distinctly important ways I call these “AJAX requests” – they run in the background, invisible to the user These AJAX requests are subjected to the SOP
the internet can load and execute JavaScript in your browser • Obviously some big security concerns • Browsers address this by limiting what JavaScript can do. • Two main security boundaries: • Sandbox • JavaScript should never escape the browser and access your host • Same Origin Policy (SOP) • JavaScript should only see and access data associated with the origin it was loaded from 23 Browsers recognized the danger of executing arbitrary JavaScript HTML CSS Document Object Model (DOM) www.example.com JavaScript Storage Browser APIs Cookies Origin
JavaScript can see/access to only the origin it is loaded from 24 Without the SOP, the web would be a very, very dangerous place HTML CSS www.example.com Origin A HTML CSS www.chase.com Origin B
the SOP, the web would be a very, very dangerous place • Without the SOP, any site you visit could load malicious JavaScript that interacted with sites you are logged in to • You visit attacker.ropnop.com and as soon as the page loads: • A request is made to Chase to transfer money • A request is made to Amazon to order a new Macbook • etc… • An attacker would just force your browser to do some very bad things
a stricter definition 26 Assume JavaScript is loaded from https://www.example.com/home/homepage.html, which of these resources are considered to be the same origin? a) https://example.com/login b) https://www.example.com/api/profile c) http://www.example.com/images/profilepic.png d) https://api.example.com/v1/users e) https://www.example.com:8443/db/update/php
a stricter definition 27 Assume JavaScript is loaded from https://www.example.com/home/homepage.html, which of these resources are considered to be the same origin? a) https://example.com/login b) https://www.example.com/api/profile c) http://www.example.com/images/profilepic.png d) https://api.example.com/v1/users e) https://www.example.com:8443/db/update/php Answer: B only Origins must match on three parts: • Scheme (https) • Host (www.example.com) • Notice the subdomain (www)! • Port (443)
be included somewhere in the HTML that was returned from the server • Most commonly in a <script> tag, but JavaScript can be loaded in a number of other ways as well 28
concepts: • HTTP • HTML • JavaScript • As developers, you are already way ahead of most security professionals in understanding these concepts ☺ • Can break security concerns into two categories: • Client Side • Attacks that target users • Server Side • Attacks that target providers • “Backend” vs “Frontend” 29
list curated from industry data and updated every 4 years • The “Top 10 Web Application Security Risks” • This is not an exhaustive list, and it is not a “standard” • It is a reference to understand the state of web security and common vulnerabilities • OWASP also publishes cheat sheets and remediation guidance for each of these vulnerabilities 30
break these up into 2 categories: • Technical Vulnerabilities • These occur at the code level when unexpected input is given • Can be spotted in code or with scanners • Design Vulnerabilities • These are weaknesses in process, logic or design of a web application • Much harder to spot with scanners/tools Technical Technical Technical Technical Design Design Design Design Design Design
complicated with lots of convoluted JavaScript and hot new frameworks • At the end of the day though, every web application is just: • A client, talking to a server, over HTTP • Testing web applications is always just a matter of reading, sending, and modifying HTTP 34 GET /index.html HTTP/1.1 HTTP 1/.1 200 OK GET /main.js HTTP/1.1 HTTP 1/.1 200 OK GET /meme.jpg HTTP/1.1 HTTP 1/.1 200 OK
about sending custom HTTP • How can we do that? • We could just open a TCP connection and write HTTP manually… • But a better way is to use a proxy! 35 GET /index.html HTTP/1.1 HTTP 1/.1 200 OK GET /index.html HTTP/1.1 HTTP 1/.1 200 OK
two security focused web proxies • Proxies let us view, pause and modify HTTP traffic in transit • The majority of webapp attacks are based on sending unexpected HTTP requests to a server that doesn’t handle them appropriately 36 “Good” Request WTF Response Modified “Bad” Request WTF Response These “WTF Responses” are what security testers live for ☺
Traffic is encrypted end-to-end • We are intercepting and tampering with our own browser and traffic – we can configure the browser and proxy to decrypt for us • This only works because we explicitly disable some security protections – we can’t intercept someone else’s TLS traffic 37 We’ll configure Burp Suite and Firefox later on for the Lab
be designed to handle the unexpected Never assume the “happy path” – you’ll be very unhappy when it’s not taken 38 “Never, ever, under any circumstance, not even for a second, ever even consider trusting user input” - Ronnie Flathers
attacker is able to force a victim’s browser to execute JavaScript within a trusted origin • It’s a terrible name. Don’t think about “cross-site” – it’s all about loading and executing JavaScript within the same site (“origin”) • XSS allows an attacker to completely bypass the Same Origin Policy by getting their JavaScript to run in the same origin as the site they wish to target • This is accomplished through content injection in which malicious JS is injected in a valid HTTP response from the origin 40
is “smuggled” inside a legitimate HTTP response so it is executed inside the origin 41 SOP disallows an attacker’s script from interacting cross-origin HTML CSS www.chase.com Origin A Attacker Origin B Victim
is “smuggled” inside a legitimate HTTP response so it is executed inside the origin 42 If the JS comes from the origin, however, SOP is off the table HTML CSS www.chase.com Origin A Attacker Origin B Victim
An attacker is able to load JavaScript from a trusted origin by reflecting it up to and back from the server • Usually through sending a crafted link to a victim with the JS payload embedded 43 There are three main “techniques” for content injection www.chase.com www.chase.com/XSS Hey click this link! XSS comes from trusted origin and is executed
An attacker is able to load JavaScript from a trusted origin by storing it on the server to be returned in responses • Usually through embedding a payload in a persistent field (e.g. comments) • Affects any user who visits the correct page 44 There are three main “techniques” for content injection www.chase.com XSS XSS comes from trusted origin and is executed
• An attacker is able to load JavaScript from a trusted origin by passing it in to dynamic JS that is already loaded and executing • Usually through embedding a XSS payload in a field that becomes a JS variable and is parsed and executed 45 There are three main “techniques” for content injection www.chase.com www.chase.com/foo#XSS XSS is loaded into already trusted JS from the origin Hey click this link!
as their XSS payloads, but it really doesn’t demonstrate any severity by itself • It’s very visual and easy to spot • The most important part isn’t actually the “1” – it’s the page that says it • A better payload would be: • alert(window.origin) 46 The origin is https://www.chase.com An alert box is just a visual way to demonstrate you have JS code execution loaded inside that origin
applies – the basis of web security is over • JavaScript controls everything in that origin – and the attacker controls the JavaScript • Read sensitive data: • Cookies • Session/Local Storage • Make requests: • AJAX without user knowledge 47 HTML CSS www.chase.com The origin is “infected” with malicious JavaScript
injection” • An attacker is able to inject malicious JavaScript into an origin’s response • Since the malicious JavaScript comes from the origin, the browser trusts it and the Same Origin Policy does not apply • JavaScript is all powerful and if an attacker takes control of it, they can pretty much do anything a normal, logged in user can do on the site • XSS = Full read/write access within an origin 48
the DOM which the browser interprets • Never insert untrusted data into the DOM directly • Input Validation • Reject unexpected inputs, special characters, etc • Sanitization • Remove special characters, clean the input • Output Encoding • Escape/encode all special characters in HTML responses or when inserted into the DOM 49
templates • Most frameworks do this automatically Client Side • Never write untrusted content into the DOM directly • Avoid .innterHTML() , use .innerText() • DOMPurify • Client side frameworks • Use data binding with variables 50 function MyComponent({ mydata }) { return ( <h1> My data: {mydata} </h1> ) }
of as another “bypass” of the Same Origin Policy • According to SOP, resources loaded from one origin should not be able to write data to another origin • There are two notable exceptions to SOP however: • HTML Requests • Cookies • CSRF abuses these both 52 ww.chase.com Origin A Attacker Origin B SOP
request • e.g. a POST that writes data or performs an action • Cookie based authentication • No cookies == no CSRF • User interaction • Victim must visit attacker’s site or click a link 53 • Abuses: • HTTP’s stateless nature • Server can’t distinguish legitimate request from a forced one • Browser’s cookie behavior • Cookies are automatically sent to matching domains • HTML Requests • Not subject to SOP • No JavaScript/AJAX requests
www.chase.com includes the user’s cookies. The server thinks it is a legitimate request and processes it Hey click this link! www.attacker.com www.attacker.com/csrf
with cookies, it is up to the server to verify the request • Traditional defense is through “synchronizer tokens” • A random value is appended to each form • When the form is submitted, the server syncs the tokens to make sure they match • Requires remembering state server side. Frameworks help a lot here • Better/easier method is to use the Same Origin Policy! • SOP only applies to JavaScript • If each form submission requires some JavaScript, SOP kicks into action and helps us out 57
“pure” HTML • Must require a little JavaScript for SOP to apply • Two approaches: • Double Submit Cookies • A random value must be submitted in both a cookie and the body • JavaScript reads the CSRF Cookie value and appends it to the request • Custom Headers • A random, custom header must be submitted with each request • JavaScript sets a custom header on the outgoing form submission • Third approach? • Don’t use cookies at all! If your app doesn’t use cookies for authentication, CSRF goes away 58
the form • onClick() • JavaScript reads the CSRFTOKEN cookie value and adds it to the form • Because of SOP, this form can now only ever be successfully run from within that origin • Otherwise JS couldn’t read the cookie! • SOP defeats CSRF! 59 Modern client side frameworks can do this automatically! Angular will always read and send the XSRF-TOKEN cookie in all requests
the form • onClick() • JavaScript reads the CSRFTOKEN cookie value and adds it to the form • Because of SOP, this form can now only ever be successfully run from within that origin • Otherwise JS couldn’t read the cookie! • SOP defeats CSRF! 60 Modern client side frameworks can do this automatically! Angular will always read and send the XSRF-TOKEN cookie in all requests Server only needs to check if these 2 values match. If they do, the request must have come from the same origin
forgo cookies entirely and just use custom headers • Only JavaScript can set custom headers on outgoing requests • An AJAX request and a custom header trigger the SOP • If custom header makes it to the server – the form was submitted from the same origin! 61 Modern client side frameworks can do this automatically! Angular will always read and send the XSRF-TOKEN cookie in all requests
forgo cookies entirely and just use custom headers • Only JavaScript can set custom headers on outgoing requests • An AJAX request and a custom header trigger the SOP • If custom header makes it to the server – the form was submitted from the same origin! 62 Modern client side frameworks can do this automatically! Angular will always read and send the XSRF-TOKEN cookie in all requests Server only needs validate if that custom header is there. If it is, the request must have come from JavaScript and therefore the same origin
and Cookie behavior to not invoke the Same Origin Policy • It requires: • Cookie based authentication to only be used • HTML forms/requests only (no JavaScript!) • It allows an attacker to write data cross-origin without invoking the SOP • It can easily be prevented by forcing the SOP to be enforced via using JavaScript to read cookies or set custom headers 63
It is a server side vulnerability • Targets the server’s handling of unexpected or untrusted input • Follow the Golden Rule! • Can take many forms, depending on the technology in use: • SQL Injection • Command Injection (RCE) • Server Side Template Injection (SSTI) • etc.. 65
SQL query and inject additional SQL parameters • Sometimes need to be creative in crafting SQL statements, depending on where you are able to inject • UNION • JOIN • etc… 68 https://github.com/sqlmapproject/sqlmap SQL Injection is generally easy to automatically discover and exploit with tools
Popular methods: • Escape everything • Stored Procedures (SQL) • Object-relational Mappers (ORM)* • If you find yourself writing raw SQL – reconsider • Most frameworks have very good libraries to interact with SQL in a safe way 69 stmt = "SELECT * FROM users WHERE username='%s'".format(username) db.execute(stmt) db.fetchall() User.objects.filter(name=username)
“Use Burp Defaults” 4. “Proxy” -> “Intercept” 84 New versions of Burp Suite include an embedded, pre-configured browser Chromium based, configured to proxy through Burp
Try browsing to a site and it will “hang”, and you should see the request in “Proxy->Intercept” Click “Forward”, or disable Intercept by toggling “Intercept is On” 86
DER • Import into Firefox and Trust 88 Firefox Preferences -> Privacy & Security -> View Certificates Authorities -> Import -> Select DER “Trust this CA to identify websites”
knife” for web application testing • Contains tons of features and tools • Proxy->Intercept • Stop, drop or modify traffic to/from the server • Proxy->History • Chronological listing of all HTTP requests • Shows Requests and Responses • Target->Site Map • Hierarchical tree view of server resources • Decoder • Encode/decode data into various formats • Repeater • Send and modify the same HTTP request multiple times • Intruder • Automatically increment or inject data in HTTP requests 90
target is to hack the Justice League’s new website located at: https://watchtower.ropnop.dev 97 You don’t need any scanners or automated tools – please don’t blast the site! You should be able to find and exploit: • Registration Bypass • XSS • Reflected • DOM Based • SQL Injection • Cross Site Request Forgery • Authorization Bypass • Misconfigured CORS Ask if you get stuck or have questions!
account • Email doesn’t matter (didn't set it up) • Use your Burp Suite proxy and start working your way through the levels • If you get stuck or want help, reach out and share your screen! • You get points for each challenge completed • https://owasp.codeplatoon.ropnop.com/scoreboard.jsp • Will go until 4:15pm • Winner gets a prize shipped to them! 99
ropnop
sonic
oracle4engineer
morihirok
everpeace
shift_evolve
atty303
nwiizo
emeremyanina1234
chrishorner
sansantech
reverentgeek
chriscoyier
stephaniewalter
carmenintech
dougneiner
caitiem20
palkan
addyosmani
holman
scottboms
denniskardys
vanstee
![1 Ronnie Flathers – @ropnop – [email protected] Intro to Web](https://files.speakerdeck.com/presentations/94f3791328d44d398d9e3b943e9c1b42/slide_0.jpg){kind=link}
![Thank You Questions? @ropnop [email protected] 100](https://files.speakerdeck.com/presentations/94f3791328d44d398d9e3b943e9c1b42/slide_85.jpg){kind=link}