Learning:1. The attacker does not need access to source code or host server2. The attacker could be just being malicious. The idea can be as simple as defacing an individual or a business. It is not always a monetary implication that you should be bothered about
To get the application:1. Install docker 2. Run the command: docker run -p 3000:3000 karthikvkrishnan/vulnerableapp 3. Go to your favorite browser to access http://localhost:3000 Hands-on with reflective xss on search. Url can be manipulated to change the search. This url can be shared with other users of the system. The JS can be then executed on the client side. Url shortening is also a favourite in tricking users
All XSS can be broadly categorised in these 2 buckets
Note: There is no interaction with the code’s server
Note: There is an interaction with the server. The malicious code is sitting in the server, waiting to be accessed on a page by the victim
To get the application:1. Install docker 2. Run the command: docker run -p 3000:3000 karthikvkrishnan/vulnerableapp 3. Go to your favorite browser to access http://localhost:3000
Hands-on with persistent XSS on feedback/guestbook. Data is injected for a page that can be viewed by just about anyone Since it is not reflected on the url, there are no steps that a victim can take to be careful beforehand This can affect a much larger customer base, making it all the more dangerous
Very broadly speaking
All solutions can be selected from the ‘settings’ tab in the applicaiton
Only <> tags are validated against. But a business like github comments, or in our case, feedback could want to include rich text or images etc. So, removing possibilities of all <> does not help them
Note: ‘script’ is whitelisted, not ‘SCRIPT’ (so check for case sensitivity) Img tag (and others) can execute JS scripts even without a script tag - find possible examples from OWASP XSS cheat sheet So, it does not really remove possibilities of executing scripts. Also, remember blacklisting is worse than whitelisting.
As opposed to input validation, it can be used as a patch to softwares with existing XSS vulnerabilities. But it doesn’t still solve the problem where the business wanted rich text,images etc.
Your best bet for modern browsers. If you have to use older browsers, then it is a conversation to have with your business. It is always a trade off between usability and security that needs to be decided upon. CSP is not enabled on browsers by default. You have to opt-in to enable it.
The core issue exploited by XSS attacks is the browser’s inability to distinguish between script that’s intended to be part of your application, and script that’s been maliciously injected by a third-party.
Other examples of CSP directives: child-src Img-srcplugin-types
Show with XSS-me to find low-hanging-bugs. Also see XSS-Me Options to look at the test cases. All the tools have a disclaimer of possible false positives. So instead of relying on tools for XSS, functional tests to detect the same are probably a better bet.
Xss what the heck-!
Cross Site Scripting(XSS)
What the heck?!
❏What is our intent?
❏What is XSS?
What is our intent?
❏security-related jargons - one at a time
❏give you a guided, hands-on experience
❏apply on projects
❏take your time to learn
What this session will NOT be
❏Make you security experts
What is Cross-site Scripting (XSS)?
❏ Concept of planting scripts by misusing the powers of HTML,
❏ When web applications take data from users and dynamically
include it in Web pages without first properly validating the
❏ The victim of XSS is usually another user, instead of the host
server itself (which is just a medium)