Please enable JavaScript.
Coggle requires JavaScript to display documents.
edx.org - Web Security Fundamentals (Securely handling untrusted data…
edx.org - Web Security Fundamentals
Preventing unauthorized access
Secure authentication
Beyond password-based authentication
Social Login
OAuth 2.0
OpenID
Multi-Factor Authentication
Challenges to session management
Server-side session management
Store in Cookie > Need to protected
Securing session cookies
Network-base session hijacking > Set-Cookie: Secure flag
JavaScript-base session hijacking > Set-Cookie: HTTPOnly flag
Alternative session management mechanisms
Getting authorization right
Authorization throughout your application
Intentional and unintentional requests
Overview of this course
Conclusion
Authentication session management athorization
The Same-Origin Policy is the basis for security
Every application should use HTTPS with Strict Transport Security
Consider all data to be untrusted
Overview of best practices
Communication security
Deploy every application entirely over HTTPS
Configure TLS to support only new protocols, and prefer ciphers that ensure Perfect Forward Secrecy
Enable HTTP Strict Transport Security (HSTS) with a long max-age.
Setup Certificate Transparency (CT) log monitoring and investigate how your CA will support CT
Configure Certificate Authority Authorization (CAA) records to limit the CAs that can hand out certificates for your domain
Authentication and authorization
Use a dedicated password hashing mechanism to store passwords in a secure way
Ensure your application does not leak information about existing accounts
Offer two-factor authentication, but stay clear of SMS-based verification codes
Add the Secure cookie flag to all cookies, and the HttpOnly flag where relevant
Implement proper CSRF defenses
Check every entry point of your application to see if it contains appropriate authorization checks
Untrusted data on the server
Execute system commands by using an API that separates the command and its arguments
Never encode user input directly into a SQL query
Use parameterized statements with variable binding where possible
Use whitelisting when variable binding is not possible
Only use encoding as the last resort
Untrusted data on the client
Apply context-sensitive output encoding to all simple outputs in a page
Use sanitization for output that requires the use of particular code constructs
If you modify pages within the browser, apply the same set of defenses to mitigate DOM-based XSS attacks
Leverage the isolation offered by the Same-Origin Policy to compartmentalize your application
Enforce additional restrictions on untrusted content using the sandbox attribute
Deploy Content Security Policy as a second line of defense. Note that CSP is quite complex, so focus on the other defenses first.
Securely handling untrusted data
Introduction
The root cause of injection attacks
The problem with untrusted data
A decade of mitigating injection vulnerabilities
Server-side injection attacks
SQL injection
The application does not provide enough context information to distinguish data from code
Preventing SQL injection
Input Validation as a first defense
Encoding data for use in SQL Statements (last resort)
Command injection vulnerabilities
Preventing command injection
Input Validation
Using safe APIs
Preserve context information until execution encoding the data for the right context use context-aware safe APIs
Client-side injection attacks
Traditional XSS attacks
Reflected XSS: payload in request and response, original definition of XSS
Stored XSS: payload in database, attack happens within the application
Common defenses against XSS attacks
Strict Input Validation is only a first defense
context-sensitive output encoding is the default defense
DOM-based XSS attacks
Any page that uses URI fragments is potentially at risk from XSS attacks.
https://code.google.com/archive/p/domsnitch/
Putting things into context
Recap and conclusion
Advanced client-side attacks and defenses
Alternative injection attack vectors
Injection vulnerabilities
Consequences of HTML injection attacks
HTML5 Sandboxing
Content Security Policy
2 modes: blocking mode or report only mode
second line of defense against content injection attacks
script-src 'self' >> inline script blocks are no longer executed, remote scripts are only loaded if they are whitelisted
Enable reporting feature >> report-uri
https://example.com/report-uri