An challenge for white hat hacker (web)...
Hello,
I'm studying XSS since 1 month ago, and I know pretty good stuff. So I started to look fails in real sites, but my "attacks" are only JS script: "alert('xss');". I have challenge to hackers experienced in XSS: show me a fail in http://www.njogos.pt/ and, if you have ever saw, in http://www.cplusplus.com/ . :)
I'm studying XSS since 1 month ago, and I know pretty good stuff. So I started to look fails in real sites, but my "attacks" are only JS script: "alert('xss');". I have challenge to hackers experienced in XSS: show me a fail in http://www.njogos.pt/ and, if you have ever saw, in http://www.cplusplus.com/ . :)
Last edited on
If you've spent a month trying to understand cross site scripting then you're either doing something seriously wrong or you have an incomplete resource. XSS is simply when content from a third party, such as a banner ad or an embedded link, presents itself in the context of the second party i.e. the site that the user is actually viewing. In other words it's when an iFrame impersonates the host, that's all it is. The idea is for the system that is browsing the site to think that the third party content is from the second party and therefore safe so that it can then be granted the same execution permissions.
This doesn't sound like some huge exploit or evil attack vector when I talk about it because for a properly configured browser it's not. But when Jonny Numbskull gives Facebook permission to launch applications outside of his browser, or to run Active X content without prompting him (because he thinks it's annoying to click 'ok' every time) it then becomes a problem worth paying attention to.
This doesn't sound like some huge exploit or evil attack vector when I talk about it because for a properly configured browser it's not. But when Jonny Numbskull gives Facebook permission to launch applications outside of his browser, or to run Active X content without prompting him (because he thinks it's annoying to click 'ok' every time) it then becomes a problem worth paying attention to.
@Computergeek01 that's reflected XSS. There is Persistent XSS and Non-Persistent XSS. XSS can steal, for example, cookies, or even change a database. Can steal admin rights, bypass a login prompt, etc.
You're romanticizing this technique for some reason and I really don't understand why. It's still just a third party impersonating a host regardless of the perspective of the attack. It can't steal admin rights if admin rights are never granted, it can't bypass a log in if the session ID it steals expires or if the authentication token is not constant. I've never seen a proof of concept where this attack on it's own can effect the content of a database so a link in that regard may change my opinion. This is one passive component of an incomplete tool chain that will only ever impact lazy targets and so it will not yield anything of value on it's own.
From https://www.owasp.org/index.php/Cross-site_Scripting_(XSS):
| owasp wrote: |
|---|
XSS Attack Consequences The consequence of an XSS attack is the same regardless of whether it is stored or reflected (or DOM Based). The difference is in how the payload arrives at the server. Do not be fooled into thinking that a “read only” or “brochureware” site is not vulnerable to serious reflected XSS attacks. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. The most severe XSS attacks involve disclosure of the user’s session cookie, allowing an attacker to hijack the user’s session and take over the account. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirect the user to some other page or site, or modify presentation of content. An XSS vulnerability allowing an attacker to modify a press release or news item could affect a company’s stock price or lessen consumer confidence. An XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage information resulting in an overdose. |
Last edited on
In that case it's the payload the effects the database, not the attack vector. In order to attack a DB payloads need to be customized to fit the format, it's not like passwords are always here and usernames are over there. They aren't even always in the same files so don't think that you can dump something and try to make sense of it later. Even if you some how knew the layout of your target ahead of time, XSS is still a passive attack so you have to wait for the node to come to you in some shape or form. Then, assuming you aren't sand boxed, you can certainly install a back door that will allow you to deliver what ever you want. But then you have alien code running on the target machine, that is where you get spotted and that is where your tool chain dies.
I'm not saying that XSS isn't a concern, we both know that to be stupid statement for me to make. I'm saying that, based on your past posts and what you say you want to get into, it would be a better investment of your time if you were to study other exploits. You mentioned an interest in penetration testing right? That would be a directed attack, you have a known target address that you are trying to scan for an exploit from the outside. They aren't interested in hiring people who can only tell them what kind of damage can be done by a someone who already has a foothold in their network. What you are doing now is like studying bear traps when you know that your career involves hunting with a rifle. Look into stuff like SQL injections or remote buffer over runs. Quite frankly I think you'll find these kinds of proactive attacks to be far more interesting as well.
I'm not saying that XSS isn't a concern, we both know that to be stupid statement for me to make. I'm saying that, based on your past posts and what you say you want to get into, it would be a better investment of your time if you were to study other exploits. You mentioned an interest in penetration testing right? That would be a directed attack, you have a known target address that you are trying to scan for an exploit from the outside. They aren't interested in hiring people who can only tell them what kind of damage can be done by a someone who already has a foothold in their network. What you are doing now is like studying bear traps when you know that your career involves hunting with a rifle. Look into stuff like SQL injections or remote buffer over runs. Quite frankly I think you'll find these kinds of proactive attacks to be far more interesting as well.
@Computergeek01 I have already studied SQL injection. I'm studying all the types of exploits.
Topic archived. No new replies allowed.