Top 40 XSS (Cross Site Scripting) Revision Questions with Answers

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.

Q14: Can JavaScript get access to a user’s entire history?

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?

A: In the JavaScript/CSS History hack, according to some benchmarking, two to three thousand URL’s can be tested in under 2 seconds, which is imperceptible to the user. It’s theoretically possible that many URL’s can be streamed in silently in the background.

Q16: Are all Web browsers vulnerable to this issue?

A: There is exploit code in the wild that exploits all major Web browsers including Internet Explorer, Mozilla/Firefox, and Opera.There should be no reason why the code couldn’t be ported to work any browser supporting the JavaScript/CSS ComputedStyle API’s.

Q17: Can Intranet Hacking be extended to scan other ports besides port 80?

A: Yes, but it depends on the browser. Some vertical port scanning has been achieved in Internet Explorer, but the hack largely depends on what service sends back to the browser. For example, the data received must cause the JavaScript console to error. In Mozilla/Firefox, there is a port blocking security feature that restricts connections to many well-known ports including Secure Shell (SSH) (22) and Simple Mail Transfer Protocol (SMTP) (25).This was done to prevent other forms of browser attacks. However, by using the protocol handler ftp, instead of http, this restriction can be circumvented.

Q18: Some users turn off JavaScript. Do you really need their NAT’ed IP address to carry out Intranet attacks?

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?

A: An attacker’s imagination. Or to put it another way, we don’t know. Over the last year, JavaScript malware has evolved in huge steps to the point where it is the number one threat for computer users. With the power of the browser at the disposal of a malicious hacker, and the amount of valuable research being done in the field, we are still looking at the horizon for some idea as to where this field will take us.

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.

Q35: I have never seen or heard of a serious worm that caused damage. What can a JavaScript worm really do?

A: Worms and JavaScript malware that steal sensitive information exist that cause people to be infected by Windows malware. In addition, damage is not just measured by data stolen, but also system downtime. For example, if you measure the impact the Samy worm had on MySpace servers as it propagated from profile to profile, it would be well over $5,000, the limit that makes a computer crime a felony.

Q36: How can I stop myself from becoming a victim of a JavaScript worm?

A: Turn off JavaScript and/or use a text-based browser. While these options are practically impossible in this Web 2.0 world, it is about the only option available. Unfortunately, there is no easy way to stop or prevent code like this and be able to enjoy the upside of JavaScript at the same time.

Q37: I think I am infected. What can I do?

A: If you are infected by a JavaScript-based worm, close your browser.These worms reside on a Web page and use the browser to execute the code. Check your home page entry to be sure the code isn’t launching when you first load the browser. Also, disable any extensions that might contain malicious code.

Q38: Do antivirus programs detect JavaScript malware?

A: Yes. Some do detect certain aspects of JavaScript malware. Since many of these malicious programs are packaged up in a .js file, when it is downloaded to the temporary Internet directory, the scanner will detect it and prompt you for action. However, it is very easy to avoid these scanners by obfuscating the script code in a packer or built-in encryption/ decryption engine. As in the PC malware world, a truly dedicated malware writer can bypass almost any anti-virus software.

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/

You may also like:

Related Posts