Tag Info

Hot answers tagged

49

Plaintext injection is an issue. Say you have a page template that looks like this: Hi <name>, Blah blah blah. And you can inject from the URL. An attacker can construct an email with a link to ...


39

Cross site scripting is not a threat to the integrity of your web server. Rather, the problem is that an attacker can craft a site.com URL that will execute arbitrary JavaScript. If your users trust your site and allow it to do whatever it wants, this could be a major security hole.


26

In a cross-site scripting attack, the malicious script is run on the client, but the actual flaw is in the application. That doesn't necessarily mean that it is a strictly server-side vulnerability, in that the flaw could be in the application's JavaScript, but generally, it is indeed in server-side code, and always in code that is delivered by the server. ...


20

Imagine if the injected text was: "></script><script>alert("hi");" which would make it look like this: <script src="http://www.site.com/ajax/ads.asp?callback="></script><script>alert("hi");""></script> Then, you have a working custom script that can do anything it wants in the page.


17

I'm generally a fan of not re inventing the wheel because people way smarter than us already did. I did a quick search for you and found the current library you can use: https://code.google.com/p/php-antixss/ Re: your code, it looks a little too simple to prevent fully. I would use a standardized solution that is used by others and continuously contributed ...


7

It manifests itself on the client side, but that is because it is allowed to do so by the web application. The application doesn't validate the code that it sends back to the browser. And thats why it is a server side vulnerability. Think about it this way. What would you do to fix the issue of XSS? Fix the server side code or fix the browser?


6

No, it is not. Try insert javascript&colon;alert(9) as the URL, or like @wireghoul pointed, JAVASCRIPT:alert(9). Even with javascript :alert(9) in older browsers (IE < 8, I guess). Better solution: <?php header('Content-Type: text/html; charset=utf-8'); header('X-Content-Type-Options: nosniff'); $site = $_GET["url"]; $site_lowercase = ...


5

Generally speaking, no, this is not a Cross Site Scripting (XSS) issue. You can have three problems: If the attacker control the first bytes of the output, the Rosetta Flash attack can be used to trigger a Cross Site Scripting (XSS), regardless of the content-type of the page. But if you start the output with /*, like you said you do, I can not see any ...


5

Don't rely on using your own "conversion" rules, OWASP recommends using a security-focused encoding library to make sure the necessary rules are properly implemented. Escape the following characters with HTML entity encoding to prevent switching into any execution context, such as script, style, or event handlers. In addition to the 5 characters significant ...


4

It depends on where within the HTML document the data is printed as there are different contexts within different rules. Replacing a literal < by &lt; is only viable when < is a special character, which would change the current parsing state. There is a quick overview of prevention rules in OWASP’s XSS (Cross Site Scripting) Prevention Cheat ...


4

Depends on a lot of factors. If the malicious input (all user's input is malicious by default) is echoed just to your HTML body and your server sends the headers "Content-Type: text/html; charset=utf-8" and "X-Content-Type-Options: nosniff", the answer is yes, this method is secure enough. When I say HTML body, I am supposing you are echoing the input to ...


3

They're just as vulnerable as any other software would be to a vulnerability, so to your specific question it would be just as vulnerable. Remember though that in the case of shellshock the honeypot would have to be passing input to a bash shell to be vulnerable. Of course, is another component on the system is vulnerable, the honeypot could still be ...


3

Cross-site Scripting (XSS) attacks can generally be categorized as one of: Stored XSS Attacks Reflected XSS Attacks DOM Based XSS Attacks The attack itself is taking place on the client. All three attack types could fully manifest themselves in the browser itself in the case of a single page or offline application. However, if the data is stored on the ...


3

This is very bad practice. You are keeping a blacklist. But recommended way is keeping a whitelist which give only allowed chars after a filter. Answer to your question is, < can be hex encoded and write in other encoded schemes. So Simply replacing < with &lt; would not be adequate.


2

Updated browsers will encode the referrer URL. So your examples will not work to trigger XSS nowadays. Try this: <div id="cat"></div> <script> document.getElementById("cat").innerHTML = decodeURIComponent(document.referrer); </script> JSFIDDLE: http://jsfiddle.net/y4afy8h9/1/?<img%20src=x%20onerror=alert(9)>?


2

Depends on the context. A very short one: Context: <script src="%XSS%"></script> Let's say you are the owner/maintainer/administrator of http://.to (Tonga gTLD). <script src="//to"></script> XSS with 4 chars. Probably one of the shortest possible. There are dozens of other contexts. Edit: Tested on Chrome ...


2

<a href=”http://www.mypage.com/page.asp?var1=<%=server.urlencode(var1)%>”> Here you are here injecting content into a URL component, inside HTML. So in principle the correct thing to do would be to URL-encode the variable, and then HTML-encode the output of that: <a href="http://www.mypage.com/page.asp?var1=<%= ...


1

There is an attack that uses this exact attack vector, called Rosetta Flash (CVE-2014-4671). As explained on the Rosetta Flash page, the vulnerability is that: With Flash, a SWF file can perform cookie-carrying GET and POST requests to the domain that hosts it, with no crossdomain.xml check. This is why allowing users to upload a SWF file on a ...


1

Any software needs to be maintained. Honeypots are no exception. Because honeypots are designed to be probed and hacked, they need to be placed in a separate and secured environment with the understanding that they may be completely overtaken. Make sure the servers that honeypots are running on are part of your regular patch management process, and make ...


1

His point of contention was that it can bypass crossdomain policies if someone visits page with this in it: <script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script> Yes, he's right. But that doesn't seem to be a security hole, instead, it looks like a feature. This technique of circumventing the same-origin-policy is ...


1

Correct although technically you should URL encode then HTML encode for output to a HTML page. However, the ASP URL encode function URL encodes the required characters to prevent output escaping from the HTML attribute context and also does not output any characters that should be HTML encoded. When showing an image I would also validate var1 to ensure it ...


1

Inside the element, the parsing mode is in data state. The only special characters that can escape data state are < and & (http://www.w3.org/TR/html5/syntax.html#tokenization sec.8.2.4.1). If you replace all instances of < with &lt; then you only need worry about &. In HTML4 and XML, you would need to consider which entity references are ...


1

There's a ton of ink written on the subject of why you shouldn't try doing your own homebrew filters for these things! Please have a look at OWASP's XSS mitigation guidelines. Use the proper libraries for these things - OWASP ESAPI for PHP is a great tool to start with. I'd look at HTML Purifier as well.


1

It isn’t sufficient, no. Contrived backslash example: <script> var param1 = '{{ param1 }}'; var param2 = '{{ param2 }}'; </script> param1=\&param2=;alert(1)// <script> var param1 = '\'; var param2 = ';alert(1)//'; </script> Not to mention that your data won’t survive intact: <script> var param1 = '&lt;'; ...


1

The terminology is a little slippery, but usually an "XSS bug" is a client-side exploit of a server-side vulnerability. Cross-site scripting is not, in and of itself, a security problem. The problem is that it can happen without the end user's knowledge. Most sites aren't coded for this to happen, of course: either they don't use cross-site scripting at ...


1

You might need to re-read the advisory, the important part is this: A text containing carefully mixed square and angle brackets confuses the splitting process and results in HTML code getting partially texturized. An attacker can exploit the bug to supply any attributes in the allowed HTML tags. A style attribute can be used to create a ...


1

Where are you parsing out the <? If it is on the client, then you have have only maybe stopped a ten year old hacker (but not this ten year old hacker). However, if you are parsing out the executable code server-side, then yes, you've effectively stopped this particular form of injection -although there are more complete and secure ways of doing this. ...



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