Tag Info

New answers tagged

0

Doesn't the yui compressor make it difficult for human readability? In any case, you shouldn't do validation just on the client side. Remember, it's not called client server for nothing, so let the server do most of the work. The thing to remember is the world wide web was never meant to be opaque to the endpoint. That moniker belongs to native applications. ...


0

Options: Load propitiatory client side JavaScript code after the user has logged in to the web site. If you still don't want authenticated users to see the JS code, then load a JS on the client that calls another JS file that runs on the server or call a service such as a WebAPI. Off course, you want to secure the communication channel, perhaps using ...


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

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


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

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


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.


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


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


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.


0

I firmly believe in a completely separate login/logout page. It's better for conveying to the user they have been logged out. If only one part of the page changes, then it would be easy to overlook if a user didn't successfully log out.


0

Encrypt the content using a session key while in transit. Decrypt the content in-memory using a variable. At logout, explicity clear the variables containing keys and decrypted information. Also explicity clear any variables containing authentication information and any information that was used to generate the session key. The session key can be generated ...


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


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


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


0

Considering that these are static resources I don't think these are attacks. I have no idea what it could possibly be... this suggestion doesn't even make sense, but maybe a random syntax of parameters that prevent server side caching. Maybe certain crawlers use this. It's weird because it's not even requesting specific files in the directory it looks like. ...


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


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


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



Top 50 recent answers are included