The below questions and answers are designed to both measure your understanding of the concepts of XSS -Cross Site Scripting Attacks and Prevention.
Q1: What is the difference between HTML Injection and XSS?
A: Both of them refer to exactly the same thing. In one of the situations, the attacker injected valid HTML tags, while in the other one, the attacker injected HTML tags but also tried to run a script.
Q2: Does my anti-virus software protect me from XSS attacks?
A: No. Ant-virus software protects you from viruses and other types of malicious code that may be obtained from a XSS vulnerability. Some ant-virus software can detect known types of malware, but they cannot prevent XSS from occurring.
Q3: Can XSS worm propagate on my system?
A: XSS worms affect Web applications and the only way they can spread is by exploiting XSS vulnerabilities. However, there are many browser bugs that can exploit your system as well. In that respect, XSS worms that contain browser bug exploits can also compromise your system.
Q4: XSS attacks can compromise my online account but not my network. Is that true?
A: The browser is a middleware technology that is between your trusted network and the untrusted Web. Every time you visit a page, you silently download scripts and run it inside the context of the browser.These scripts have access to internal network addresses and as such can also propagate inside your network.
Q5: Does it mean that all AJAX applications are vulnerable to XSS attacks?
A: Although the majority of the Web applications have XSS issues, it is important to understand that XSS is caused by server/client side scripts, which does not sanitize user input. If you follow a strong security practice, you can prevent XSS from occurring by filtering or escaping undesired characters.
Q6: Why should I care about DOM? Isn’t that a developer thing?
A: DOM is the single most complete object that represents the structure of the Web application you are testing. Although, in general a lot of the vulnerabilities are discovered on the server, very often we find vulnerabilities on the client. Most of these vulnerabilities are related to DOM-based XSS.They are very hard to find, but if you master the DOM tree you will be able to detect them quicker.
Q7: What is the difference between user scripts and bookmarklets?
A: In general, user scripts a lot more powerful then bookmarklets, although bookmarklets are cross-browser while user scripts are not. In certain situations you might need to access resources that are in a different origin. User scripts are the right solution for this. Bookmarklets are suitable for creating tiny utilities that work inside the current page.
Q8: Can I autorun bookmarklets in other browsers than Firefox?
A: Not unless you extend the browser with this type of feature. Autorunable bookmarks are not supported by browsers.The GNUCITIZEN Technika Firefox extension was developed to target this particular weakness.
Q9: Are persistent XSS vulnerabilities more severe than non-persistent ones?
A: It depends on the site where XSS issues occur. If the site requires authentication to inject the persistent payload, then the situation is less critical especially when the attacker doesn’t have access to the system. If the XSS is non-persistent but it occurs on the site main page, then it is a lot more critical, because users can be tricked into entering private information as such unwillingly giving it to the attacker.
Q10: How often do you find DOM-based XSS vulnerabilities?
A: Quite often. DOM-based XSS is not that simple to detect, mainly because you may need to debug the entire application/site. However, modern AJAX applications push most of the business logic to the client. Therefore, the chances of finding DOM-based XSS are quite high.
Q11: CSRF attacks cannot read the result and as such are less critical?
A: Not at all. CSRF attacks can be as critical as XSS attacks. CSRF can perform actions on behalf of the user and as such reset the victim’s credentials for example. Keep in mind that if that occurs, the attacker will have full control over the victim’s online identity. Some home routers are also vulnerable to CSRF. In this case, attackers can take over the victim’s router and as such gain control of their network from where other attacks against the internal machines can be launched.
Q12: What else can PDF documents can do?
A: If you are in corporate environment, you most probably have Acrobat Pro with most of the plug-ins enabled. Therefore, attackers can access database connections, connect to SOAP services, and perform other types of operations totally undetected.
Q13: What is the best technique to evade XSS filters?
A: There is no best technique. In order to master XSS filter evasion, you need to have a good understanding of its inner workings and broad knowledge about Web technologies in general.
A: Not without relying on a traditional Web browser exploit. The history stealing hacks describes represent more of a brute force technique to get the Web browser to leak history information, but not a full data dump.
Q15: How many URL’s can be tested in the various history stealing hacks?
Q16: Are all Web browsers vulnerable to this issue?
Q17: Can Intranet Hacking be extended to scan other ports besides port 80?
A: No. According to RFC 1918, non-routable IP addresses are well documented and most home broadband users are using 192.168.1.0 or 192.168.0.0 ranges so educated guesses can be made. Furthermore, the DSL routers and firewalls are often located on *.*.*.1 of the IP range. These addresses can be targeted directly while blind.
Q19: Can data received from the open port be read?
A: No.The same-origin policy in the browser will prevent that behavior unless a second stage XSS attack is leveraged.
Q20: Will solutions such as multi-factor authentication, SSL, custom images, virtual keyboards, takedown services, and the like prevent this style of attack?
A: No. Those solutions are designed to help the user to either protect their password or to determine if the Web site they are on is real. In this case, the user is on the real Web site, but malicious code is monitoring all activity. Furthermore, the user is more likely to click on these types of links before the domain name is read.
Q21: Are there any client-side protections against Anti-DNS pinning.
A: There is an experimental Firefox plugin project called Localrodeo that does attempt to protect against Anti-DNS pinning attacks: http://databasement.net/labs/localrodeo/
Q22: Are other services vulnerable like IMAP3?
A: Yes, however, you are limited to what the browser will allow you to go to. In Firefox that list is crippled, but not severely. In other browsers it may be less or more restrictive. There is a paper from 2001 that describes other issues in SMTP and NNTP: http://www.remote.org/jochen/sec/hfpa/hfpa.pdf
Q23: Is MHTML really that bad?
A: Secunia lists the vulnerability as “less severe,” however, in tests it is hugely effective at reading any information from any site that has double line breaks and predictable URLs. In our estimate, it is one of the worst non-remote exploit browser bugs ever found.
Q24: Is the expected issue still vulnerable now that it’s fixed?
A: Absolutely. There are thousands of old vulnerable machines on the net that are still at risk of being used in expect vulnerability-based XSS exploits. It’s as simple as a single HTTP request to detect if it’s vulnerable.
Q25: Is JSON really a problem?
A: Today it is not that big of a deal, because relatively few sites use it. However, with the explosion of “Web 2.0” enabled applications, expect this to become a bigger risk.
Q26: Are there any secure password managers?
A: Using a password manager that automatically fills in content into a form is always going to be dangerous. Not only do you have to worry about browser-related flaws, but this behavior can be exploited by anyone who can gain local access to the system. A truly paranoid person would never store a password anywhere, would change passwords constantly, and would ensure no one compromised password could compromise another.
Q27: What are the limits of XSS attacks?
Q28: If a Web site can cause someone to be personally attacked, even if spoofed, can that Web site be held responsible?
A: While we are not lawyers, it wouldn’t be hard to imagine someone suing a Web site operator if it was used to disgrace their reputation. Given the fact that the victim in this case is the person being personally slandered, and it wouldn’t have happened if the vulnerable Web site was not exploited, the blame rests squarely on the shoulders of the malicious attacker and the vulnerable Web site. But who would take the fall?
Q29: It’s hopeless. I can’t trust a single Web application.Why did you do this to me?
A: We know the feeling and what you are experiencing is growing pains. Just like with any other field, be it wireless networking, file system encryption, or Radio Frequency Identification (RFID) systems, new technologies needed to be tested before they can be fixed. So, this is just part of the process and it will get better, though it might get worse first.
Q30: I run XYZ program that creates an HTML report. How can I determine if it is vulnerable?
A: Locate the various pieces of information in the form that come from an external resource, and then start to insert the key characters into those resources. In some cases, you may have to hack the resource just to find a way to inject code, but chances are you will probably find a vulnerable application.
Q31: How easy is it to extend AttackAPI?
A: AttackAPI is designed to be easily expended by third-party modules. All you need to do is integrate your code by using AttackAPI library conventions.
Q32: I tried to portscan with BeEF, but the result is not accurate. Is that a bug?
A: Port-scanning from the browser is not an exact science. Depending on the zombies’ browser setup, the port-scanning process will fail or succeed.We recommend you run the scan a few more times and correlate the results to eliminate false positives.
Q33: Should I approve the security-warning box when I run CAL9000?
A: CAL9000 requires extra privileges to be able to load and store files from the local file system, and also access external resources circumventing the same origin policy. For that reason, you need to give the application extra permissions. CAL9000 is safe and should not harm your system.
Q34: Is the browser-hijacking feature in XSS-proxy persistent?
A: No.The attacker will have control over the hijacked browser window/tab for as long as it is open or the user does not use the address bar to open other resources.
Q37: I think I am infected. What can I do?
Q39: Is there a safe browser?
A: All modern browsers carry some risk, and all modern browsers can be crippled to the point where they are secure but in doing so they become nearly unusable.
Q40: Is there a function that can be used to completely stop XSS?
A: Depending on the scenario, you can often remove all XSS by simply removing open and closed angle brackets; however, the nuances of exploitation make this a risky rule of thumb. For a very good PHP filter look at HTML Purifier at http://hp.jpsband.org/