Goals of Web Security
- Leak Prevention
- Prevent unauthorized access of information owned by the organization (business, school...)
- User Privacy
- Prevent unauthorized access of other users' information
- Other users by logged-in users
- All users by logged-out users
- Legally required!
Goals of Web Security
- RCE on Server
- Prevent code that is unauthorized/unknown/dangerous/etc. from being run on the server by people outside of the organization/business.
- Ransomware
- Miners
- Proxies & Botnets
- XSS
- Cross Site Scripting. Unauthorized code or actions running on the client, usually the browser.
- Reflected
- Persistent
- DOM-based
- Server
- Client
Goals of Web Security
- CSRF
- Cross-Site Request Forgery.
Any action that appears to be taken on an authorized user's behalf but isn't actually... including GET.
- SSRF
- Server-Side Request Forgery.
Any action that appears to be taken on an authorized server/service's behalf but isn't actually... including GET.
- DoS
- Denial of Service.
Anything that causes the web site or web service to be unable to serve its normal users.
High-Value Targets
- Personal Information
- Private Information
- Ransom-able Information
- Compute Resources (Mining)
- Network Resources (Proxy/Botnets)
What's Getting Exploited
Mitre's Top 25 Weaknesses. (Includes non-Web weaknesses.)
Is your website supposed to...
- Distribute malware/worms/viruses?
- Vouch for the identity of fraudsters?
- Send spam?
- Distribute pirated software/media?
- Run crypto-miners?
- Host pornography?
- Help attack other services?
XSS (Cross-Site Scripting)
- Doesn't need to come from another site
- Inclusion of unauthorized HTML/CSS/JavaScript in page.
- Malicious code that runs in the browser.
- Malicious code that runs on the server is not XSS, it's RCE.
XSS Types
Where does the bad code come from?
- Server
- URL navigation,
<script>
, <link
, src=
, ...
- Client
- Bad code comes from an AJAX call.
- DOM
- When bad code is generated by code on the client that modifies the DOM.
XSS Types
How long is the malicious code around?
- Reflected (Type 1)
- Provided by a single server response as an immediate response to a malicious request.
- Persistent (Type 2)
- Provided by any number of server responses. The malicious code is stored on the server.
XSS Types
|
Server |
Client |
DOM |
Reflected |
Reflected Server XSS |
Reflected Client XSS |
Reflected DOM XSS |
Stored |
Stored Server XSS |
Stored Client XSS |
Stored DOM XSS |
Reflected Server XSS Example
- Error page generated server side that complains about incorrect query parameters.
- Error page shows user their incorrect query parameters.
- Error page does not stop contents of query parameters from being interpreted by the browser as HTML/CSS/JS code.
Stored Server XSS Example
- User profile page on server allows user to enter a description or bio for themselves.
- Bio is stored on server.
- Anyone navigating to the page sees the user's custom bio.
- Someone sets their bio to contain HTML/CSS/JS.
XSS and URLs
someAElement.href = "http://mysite.com/?q=" + searchQuery
someAElement.href = "http://mysite.com/users/" + userName + "/profile"
Server XSS Prevention
- Check incoming POST/GET parameters, paths, & uploads for validity.
- Should a user be able to enter their name as
<script>
?
- Apply HTML/CSS/JS escaping to anything filled in.
- Example: Use built-in library functions to change
<
to <
in HTML.
XSS Prevention
- Avoid "unsafe sinks"
.innerHTML
(react: dangerouslySetInnerHTML
)
document.write()
.onevent
eval()
setTimeout(string)/setInterval(string)
XSS Prevention
- Use safe sinks instead
.innerHTML
→ .textContent
document.write()
→ create elements the OO way
.onevent
→ addEventListener
eval()
→ Just don't.
setTimeout(string)/setInterval(string)
→
if (typeof somecode === 'function') {
setTimeout(somecode);
} else { throw new Error("Possible XSS?"); }
Apply Escaping EVERYWHERE
Apply Escaping EVERYWHERE
Apply Escaping EVERYWHERE
Lock it down!
- HTTP:
Content-Security-Policy: default-src: 'self'; img-src https://*;
- HTML:
<meta http-equiv="Content-Security-Policy" content="default-src: 'self'; img-src https://*;">
- Unlock inline CSS:
style-src: 'unsafe-inline';
'self'
value means only other URLs on the same source (domain, http/https & port number) can be used.
- Only listing
'self'
prevents use of inline data.
CSP
- Example
script-src: 'self'
:
<script src="/scripts/banana.js"></script><!-- this one loads ok -->
<script src="https://some.cdn.com/somelibrary.js"></script><!-- not allowed, different origin -->
<script>
alert("This one doesn't load, it's unsafe inline.");
</script>
<button onclick='alert("this one doesn't load either, unsafe inline")'>
CSP
- General approach
- Set
'default-src: self;'
and see what breaks.
- Add exceptions as needed
or
move things out of inline.
Cross-Site Request Forgery (CSRF)
- Trick a user or user-agent into executing malicious requests.
- Hijack weak authentication measures.
- Repeat actions unnecessarily.
Cross-Site Request Forgery (CSRF)
- Server-side ("Classic") CSRF
- Server cannot tell if request is coming from a legitimate client/user or not.
- Client-side CSRF
- Legitimate Client-side JavaScript running in the authorized user's browser is tricked into sending an unwanted, or malicious request.
Server-Side CSRF Mitigation
- Check
Referer
header.
- Request tokens
Server-Side CSRF Mitigation
- Include bearer auth with AJAX that isn't public GET.
- Make sure unsafe actions (actions that change state) aren't GET.
/logout
should not be a GET
- Apply XSS prevention
- XSS & CSRF are often combined!
CSRF Mitigation
- Naive Double-Submit Cookie
- Server sets random cookie on first visit.
- When any request is made, browser always sends cookie.
- Also send cookie as a hidden form field or with custom header in AJAX request.
- Browsers only allow custom headers to be set for same-origin requests!
- Server double-checks they match.
Path Traversal Exploit
- Using relative paths like
.
..
.
./././etc/passwd
Path Traversal Mitigation
- Reject
/
in things like names in the first place.
- Reject sequences such as
..
, /..
, ./
- Don't use regular expressions to check these 💀
- Use path library to convert relative path to absolute path, and check that it's still in the correct folder
Preventing SQL Injection
- Never construct an SQL query from strings!
- Use placeholders instead!
# Python/sqlite3 example
import sqlite3
con = sqlite3.connect("mydatabase.db")
con.execute("SELECT * FROM user_table WHERE name = " + user_name + ";") # BAD WRONG DO NOT
con.execute("SELECT * FROM user_table WHERE name = ?;", (user_name,)) # good yes do do this
Shell Injection
- Like SQL injection
- But with shell commands (command-line commands)
- Unix/Linux/MacOS
sh
- Windows
cmd
& powershell
Preventing Shell Injection
- Validate paths and names
- Don't execute commands as shell commands, do direct exec...
import subprocess
subprocess.run("program operation --option " + file_name) # BAD, will be run with system shell
subprocess.run(["program", "operation", "--option", file_name]) # GOOD, run directly
Poorly Secured Cookies/Tokens
- We want the server to go stateless!
- We want the client/user to remember the state, not us!
- So let's use cookies or tokens and make the browser/client remember it.
Poorly Secured Cookies/Tokens
- What if they forge or tamper with the cookie/token?
- What if the cookie/token gets stolen?
- Does the hacker even have to log in?
- What if the cookie/token gets reused?
- What if the cookie/token gets repeated?
- Hackers can change data even when it's encrypted.
- It might not decrypt to something that makes sense anymore, but that's fine if it lets the hacker do what they want!
- Integrity must also be protected.
- Rely on secure hash functions
- Salt hashes
- Key hashes
- Hash the WHOLE thing (entire message plus important context)
- Single Service creates messages (tokens) that it can verify it created:
- Rely on secure hash functions (not your own, not MD5)
- Salt hashes
- Key hashes
- Hash the WHOLE thing (entire message plus important context)
- Hash the encrypted text if encrypting (EtM)
- Use different keys for hash and for encryption
- Two services that need to verify the other created messages:
- Actually it's better to just use a widely-known library...
- Making your own encryption code that's actually secure, rather than just looking secure, is difficult!
Tokens are not that safe...
- Include info in tokens about:
- When it was made
- For who it was made
- For what IP it was made
- When it's expected to expire
- What purposes it can be used for
- What backend version made it
- What frontend version requested it
DoS Denial of Service
- An attacker makes a service unavailable
- Common methods:
- Spamming
- Flooding
- Filling queues with large requests
- Sending useless expensive jobs
- Using all available Resources
DDoS: Distributed DoS
- Same thing as DoS when the attacker has
- Many computers (lightbulbs)
- or computers all over the world
- or computers that will Reflect requests
- or some way to redirect or reroute legitimate traffic to the target
Non-Distributed DoS Mitigation
- Limit CPU time/RAM/disk per request
- HTTP 517 Insufficient Storage
- Limit request size
- HTTP 413 Content Too Large
- Limit requests per second per user
- HTTP 429 Too Many Requests
- Limit users per IP or network
- Limit clients per user
- Limit ...
CAPTCHAs
- HTTP 402 Payment Required
DDoS Mitigation
- Look for patterns in traffic and filter out that pattern
- Specific requests/endpoints/paths?
- Specific areas of the world?
- Specific user agents?
- Specific HTTP headers?
DDoS Mitigation
- Maintain white-lists of known-good request sources
- Only allow users who were logged-in before the attack started
- Only allow IPs who accessed before the attack started
- Use IP "reputation lists"
- Session cookies from before the attack started
DDoS Mitigation
- Pay for cloud-based caching & DDoS defense reverse-proxies
- Fastly
- Akamai
- Cisco Umbrella
- ...
- Host your own caching & defense reverse-proxy...
- HAProxy
- BunkerWeb
- FastNetMon
- Various HTTP server (nginx, etc.) config and plugins
- ...
License
Copyright 2014-2023 ⓒ Abram Hindle
Copyright 2019-2023 ⓒ Hazel Victoria Campbell and contributors
The textual components and original images of this slide deck are
placed under the Creative Commons is licensed under a Creative Commons Attribution-ShareAlike 4.0 International
License.
Other images used under fair use and copyright their copyright holders.
License
Copyright (C) 2019-2023 Hazel Victoria Campbell
Copyright (C) 2014-2023 Abram Hindle and contributors
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN.
01234567890123456789012345678901234567890123456789012345678901234567890123456789
CMPUT 404 Web Applications and Architecture Web Security Created by Abram Hindle ( abram.hindle@ualberta.ca ) and Hazel Campbell ( hazel.campbell@ualberta.ca ). Copyright 2014-2023.