New answers tagged

2

No. If the user input is properly encoded (HTML encoding in this context), XSS is not possible as user input will never be treated as JS code. Proper HTML encoding (conversion of input into their HTML entities) is the preferred way of preventing XSS when any user input is inserted/reflected back within HTML code. Your example seems to be a case of DOM ...


0

There is no security bug here. If somepage.html links to malicious.html, they are both located on the same domain. It is expected behavior that the opened document malicious.html has a back reference via window.opener. In the same way somepage.html could access malicious.html by creating a handle for the opened document: var other = ...


6

Yes, in the past there have been lots of exploits that only relied on malicious HTML and CSS code. You are right in that parsing a complex, turing-complete language is potentially more error-prone, giving an attacker more tools to craft an exploit. Yet, there are many different ways in which the implementation of the used CSS parser or other modules ...


0

Yes, your SVG can easily be altered to execute arbitrary code. You have a reflected XSS vulnerability right there. When you have <svg width="<?php echo $_GET["name"];?>" height="100"> <circle cx="50" cy="50" r="40" stroke="green" stroke-width="4" fill="yellow" /> </svg> Set name be equal to 40"> <script> ...


0

White-listing the characters is always the best practice instead of black-listing special characters. I had seen the same thing with one of the apps I was assessing. So, I found an input parameter which showed in response at three different places. One of which was inside " " in a-tags. No wonder, XSS was easy there. And yes, already mentioned, many of the ...



Top 50 recent answers are included