Security
OWASP Top 10
- Injection
- Broken authentication (sessions handled incorrectly, assuming another user’s identity)
- Unprotected sensitive data (data stored in plain text at rest etc.)
- XML external entities being evaluated
- Broken access control (roles - permissions for authorized users)
- Security misconfiguration (insecure defaults, verbose error messages)
- XSS
- Insecure de-serialization (replay/injection attacks, privilege escalation, remote code execution)
- Vulnerable components (libraries not updated etc.)
- Insufficient logging/monitoring
Injection
Any time an application uses an interpreter of any type there is a danger of introducing an injection vulnerability.
When a web app passes information from an HTTP request as part of an external request, the input must be sanitized. All injection attacks are input-validation errors.
All external input is a threat; text inputs, check boxes, cookies, HTTP headers etc… Never rely on client-side validation.
Command injection: when unsanitized user input is part of a shell command.
Authentication
Authentication: establish claimed identity
Authorization: establish permission to act
Authentication always comes before authorization.
Three factors:
- Something you know
- Something you have
- Something you are
HTTP
HTTP is a stateless protocol; credentials must be sent with every request. Hence, SSL should be used for everything requiring authentication.
That is, every single request needs to be authenticated and then authorized before completing any request.
Session management: some session ID cookie needed as HTTP stateless; often exposed on the network
Side-doors: change password, forgot my password, secret questions etc.
Mitigation
Architecture:
- Authentication should be simple, centralized and standardized
- Use the standard session ID used by your container
- Be sure SSL projects the credentials and session ID at all times
Implementation:
- Check SSL certificate
- Examine all auth-related functions
- Verify that log off actually destroys the session
XSS
Attacker gets malicious script into a web page that stores data on the server; this script now has access to everything on the page, including DOM and cookies.
e.g. intercepting login requests and redirecting to an attacker-controlled website.
DOM-based XSS Injection:
- Untrusted data should only ever be displayed as text
- JS encode and delimit untrusted data with quoted strings; just looking for quotes isn’t enough (backticks, nice browsers correcting ‘sloppy’ markup, escape sequences etc.)