Tag Info

Hot answers tagged

14

Yes. You should always escape untrusted data. Here's an attack for your snippet (pseudocode): <noscript> <img src="<?php echo 'you should always escape everything, dependeing on the context. This context is url in an attribute, you should escape it appropriately. otherwise " /> ...


13

It is a security measure, as the description in the code implies. The iframe serves as a protection mechanism against XSS exploits through browsers' own measures against these very same attack types by preventing JavaScript access to frames and iframes when they're not published on the same domain. It isn't really necessary to write this part of HTML ...


11

I see a few reasons why not to do that: The client browser may (and probably will) cache the received HTML page into some file on the local disk. It is usually not a good idea to have passwords "as is" in files on the disk. Since you store data on the client side (in the HTML), you must think about what happens when the client does not cooperate, i.e. ...


11

When I do pen tests, I report an issue if a form field asks for sensitive data (e.g. a credit card number), is NOT a password field, and does NOT have autocomplete=off. The rational is that browsers manage autocomplete for passwords quite sensibly: they give the user the option of whether to store the password, and (most) users can make a sensible decision. ...


9

Yes, almost all HTML tags allow you to declare an event handler. Some of these events could be triggered when the page loads without user interaction: <img src=x onerror=alert(1) /> Event tags are not the only way to trigger xss: <a href=javascript:alert(1)>xss</a> One possilbe solution is to set the Content Security Policy for this ...


9

Banning opacity on elements containing an iframe would have negative impact of user interfaces (eg no nice fade effects when iframes are in play), but would not block clickjacking attacks. Even if transparent iframes were impossible, you could still achieve all the same attacks by using a 1x1 pixel iframe that followed the pointer. Positioning inside that ...


8

As far as I know the following ways can be used to refer to an svg. <img src="http://example.com/some-svg.svg"> Any tag with css styles. e.g. style="background-image:url(http://example.com/some-svg.svg) Filtering on extensions is not enough. HTTP headers determine the content type, not the extension. A .jpg file may be read as an SVG. Therefore, any ...


8

Pros It can improve security when authenticating (in addition to a multi-factor device) If used as a "client certificate", it can make MITM attacks much more difficult The Keygen tag is implemented across most non-IE browsers, making it very easy to implement Works regardless of administrator permission. With IE Active X controls can be disabled and IE ...


8

The problem is that this one setting simultaneously controls the behavior of two similar but sufficiently dissimilar functions in the browser such that an optimal result is difficult to achieve. First, we have what you might call "smart" or "naïve" or "automatic" auto-complete. This is the original auto-complete technology. As you fill in forms on various ...


7

Yes. It's trivial. <div onmouseover="alert(1)" style="position:fixed;left:0;top:0;width:9999px;height:9999px;"></div> Might want to save your work before trying that, though - the alert might show repeatedly as you move your mouse across the screen. Of course, a better attack would involve destroying the div as soon as the JavaScript is ...


7

Let's look at the technology stack of a dynamic website: Your code, in whatever language you chose, e.g. PHP or ASP.NET The script engine, e.g. PHP engine or .NET CLR The web server, e.g. Apache or IIS System services, e.g. SSH and FTP The operating system If you're on a VPS, the virtualisation technology that hosts your instance, e.g. VMware. The hardware ...


7

It is not clear what exactly the slide is referring to. Django's auto-escaping should be fine against HTML-injection in text content and properly-quoted attribute values. There are not other Unicode characters that can evade HTML escaping, but in principle there are byte sequences that could be misinterpreted as being in the wrong Unicode encoding: If the ...


7

A lot can still go wrong given an application that contains this small snip of code. An attacker could use a local file include vulnerability to obtain remote code execution by putting PHP code within the metadata of an uploaded image. An attacker could potentially write an image with a valid file extension in any directory using directory traversal. In ...


6

If the content of the website is very simple like you describe, then the security risk lies with the web server, the OS, the hosting infrastructure and the security of the password for the hosting. A web server can be improperly configured and security updates can be missing. Other services running on the same OS can be vulnerable to attacks. The hosting ...


6

Just to show you what this script does as it's always interesting the obfuscation techniques people use. <? #68c8c7# echo " <script type=\"text/javascript\" language=\"javascript\" > asgq=[0x72,0x65,0x6c,0x61,...0x28,0x29,0x3b]; try{document.body|=1} catch(gdsgsdg){ // Some attempt of obfuscation zz=3; dbshre=34; if(dbshre){ ...


6

The Content-Security Policy or CSP allows you to create a page of user controlled HTML that does not execute JavaScript, and therefore not XSS. This is telling the browser not to execute JavaScript, which is a lot stronger than filtering the output, and using both will improve security. HTML filtering libraries such as HTMLPurifer, antisammy, safehtml, ...


6

I've done several pentests for several banks and we always advice to disabling auto complete. The reason for this is that most users do not use a password manager and thus the password gets saved within your browser somewhere, plain text (some browsers actually do encrypt the autocomplete passwords, but that's only been done recently). This is also adviced ...


5

This seems like a silly solution to an already solved problem: Use an HTML purifier library to only allow a safe subset, OR HTML escape questionable input characters like <>'"& to their equivalents (e.g., < goes to &lt;). Additionally, if you needed to allow some formatting (e.g., users can submit links, insert bold text) use a safe ...


5

It is very unlikely that this would be a viable route to dropping a web shell. The input is probably stored in a database, not in a file, so the interpreter (ASP, PHP, etc) will not process it as source code. A much more likely attack vector is Cross Site Scripting, if the filter is not strict enough. EDIT to answer 2 points added later: There is no way ...


5

No, as it seems to indicate you are using jQuery (adept at parsing out information from HTML tags) to do input validation on the user inputting HTML that you will then display back to the user. Whitelisting safe HTML tags, and blacklisting unsafe HTML tags is the wrong method to preventing XSS. The right method is using a lightweight markup language like ...


5

You need to verify that the HTML is valid (e. g. proper nesting of ", ', <, >). Otherwise different browsers will use different algorithms to "fix" it. This results in them seeing different things as tags. Furthermore there is a high risk that you add too much to your whitelist. For example the href attribute may contain active content. For example: ...


5

I wrote a blog a while back about a security flaw in iOS's Safari Mobile browser. Which pretty much allows you to mask a URL. The hole was fixed with iOS 5.2 I believe and the hole I know for a fact is no longer available in iOS 6.x. But in short people can find such security holes in certain types of web browsers, then use them to their advantage. In the ...


5

No, I don't know any website that is doing this. Simply, because it's a silly idea. The DOM is in the memory, and when you access it you're accessing objects stored in the memory. If a website wants to do this, it would simply store the cookie in a JavaScript variable. var Cookie = 'COOKIE_VALUE'; But there are much much better ways of creating sticky ...


5

I found out what it does (please be lenient with me, I am not a javascript developer) What can be easily seen, is that the script invokes String.fromCharCode() on the numbers present on the a string to create a new String, and execute it. The code the a string get's translated to is: function zzzfff() { var klccr = document.createElement('iframe'); ...


4

It is still possible. However, it is much harder to do unobtrusively now. See the following research paper for details of how to do it: I Still Know What You Visited Last Summer: Leaking browsing history via user interaction and side channel attacks, Zack Weinberg, Eric Chen, Pavithra Ramesh Jayaraman, and Collin Jackson, IEEE Security and Privacy ...


4

The two biggest threats are Clickjacking and accessing the offline storage. The offline storage maybe accessed with DOM Based XSS or if the machine running it has been compromised. Even if your application doesn't use GET/POST/Fragment as input, one of your libraries might.


4

If the script appears in the source for the page, but when you look at the source for the page on the server you aren't seeing it, one of several things could be happening. 1) It could be your computer that is infected with malware, and not the server, and the injection is coming from something running on your computer. 2) The injection is coming from an ...


4

Good day! Edit: Sorry for the unlinked links - given that I just created my account to reply to this I have not enough "cred" to post more that 2 links per post... This post is not the freshest I reckon - but I am going to reply nevertheless. I am one of the authors of this paper you linked. And I noticed, that some of the advice given in this thread is ...


4

Congratulations! I have put some thought into this and this is actually a pretty solid escape system. Although it can lead to errors, I don't believe this is very useful to an attacker. The main reason why a character separation encoding is better than a traditional html-encode is that is causes problems with an attacker's payload. For example, XSS ...


4

You say that php scripts such as these have been directly injected into your files, which implies that an attacker has had some ability to modify files on your machines (there are multiple ways to get this). In some way, you have created the same vulnerability across all of your sites. It is possible that you have some issue that turns out to be really ...



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