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.


21

JavaScript has full access to the document object model, so at least in theory, it could capture what's on its own web page (but not anything outside the browser window) and there's a library to do that: http://html2canvas.hertzen.com/ (I haven't tried it.) The same-origin policy prevents JavaScript from accessing the DOM of another site. Since ...


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.


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

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


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

As long as you don't setup the server yourself you cannot be sure that what you are seeing with ssh is actually what is happening on the server. At the end your ssh access could just be a well built honeypot and nothing you see there relates to real server activity. Even if you've setup the server yourself you cannot be sure, because there is still 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

Besides capturing the screen with Javascript, a common thing is tracking a users mouse movements/actions on a web page. This previous question on StackOverflow shows how to capture the position of the mouse in Javascript and jQuery. With this information, people can take those mouse positions and map them with a screenshot of the web page (created using ...


2

Sorry, I can't "Comment", have to create an "Answer". This is what you are looking for: "Subresource Integrity" http://w3c.github.io/webappsec/specs/subresourceintegrity/ Summary: http://qnimate.com/how-to-make-browsers-verify-fetched-resources-content/ Subresource integrity is only supported by the latest browsers.


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

From what it sounds like this is not a problem limited to you. Many other WordPress websites have been hit. I'd expect someone to come out with a more comprehensive solution soon. That being said: ARS Technica just reported that it seems like a premium plugin called RevSlider is responsible for the security hole. Other than restoring the website from a ...


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

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

When I googled the query, I received many similar requests reported as malicious on different websites (like this one). This certainly looks like an XSS attempt. However, I don't think there's anything to worry about this particular request. The code: ...


1

Iptables can do this without any difficulty. Create a chain for the target IP address(es) and within that chain, modify the inbound request packet so that the request is for a different file. Alternatively, you could modify the outgoing packets so that they contain the target file instead of the original contents of index.html. None of the binaries or ...


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

I've seen similar services which work as a proxy and encode all your webpages in some really obfuscated Javascript, so that a real browser would have no problems browsing that site while it would be really hard, if not impossible (what if the JS was random and different with each request) for a conventional scraper to do the same. The problem is that it's ...


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

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