Hot answers tagged html
12
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. ...
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 ...
8
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 ...
7
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 ...
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 ...
6
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 <). Additionally, if you needed to allow some formatting (e.g., users can submit links, insert bold text) use a safe ...
6
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
...
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){
...
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
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 ...
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
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 ...
4
An attacker can use a URL shorting service like bit.ly:
http://bit.ly/114E7Q5
The XSS'ed site came from http://www.xssed.com/ !
If it is a phishing attack and the URL matters, then the attacker can URL-encode or UTF-8 encode key characters to obscure HTML tags. Most people disregard long urls anyway.
related: XSS filter Evasion Cheat Sheet.
3
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 ...
3
A blacklist approach will always be flawed. For example, under internet explorer you can use the vbscript: URI to execute vbscript code. There are also ways of encoding javascript: to bypass this check. There have been a large number of itunes exploits that rely upon the itunes: URI to exploit itunes from the browser. This is just two examples, but ...
3
No. It is not safe. Browsers vary widely in how they parse certain kinds of input (for especially "invalid" HTML, where "invalid" here is not especially well-defined, but sometimes even for "valid" HTML). This provides a large number of subtle ways to smuggle bad HTML into your HTML document, without jQuery realizing it.
The root of the problem is not ...
3
Yes, there are at least three instances where this XSS filter fails. XSS is complex, and blindly replacing characters doesn't solve this problem. The most obvious is if you are writing within a script tag:
<script>
var x = alert(1);
</script>
If you are writng an href or iframe src you can use the javascript: URI:
<a ...
3
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 ...
3
One great product I like to use is Nessus.
Nessus has plugins available to both import existing nmap scan results and launch nmap scans directly. I like the reporting features of the tool which will output a nice PDF report for you.
See this link for more information.
Another alternative I like to use is the Metasploit framework. While renowned as an ...
3
If you don't want to store the password on the server, why are you doing two steps to the user creation? If you are only checking username availability, why not use AJAX postback to send back only the information that needs to be verified and do everything in one form?
Even if you do need to send it back, I don't see why it couldn't be kept on the user's ...
3
By putting the clear-text password (or any sensitive data) inside the source code or the DOM of the page you are taking a big risk.
For example, just a simple Cross-Site Scripting (XSS) vulnerability makes it trivial to read that value and send it wherever the attacker wishes.
Furthermore, other techniques involving Clickjacking are used to read content ...
2
It's quite possible. The trick they've used to prevent this attack involves disabling CSS on the :visited selector. However, that doesn't stop the selector from still being there!
You can use JavaScript to iterate through a set of links, checking for the :visited selector on each. It's possible to do the check using cssRules, which should tell you which ...
2
What attack vectors are there in this kind of scenario?
DOM-based XSS is the big one.
Normally that can allow a host of things key-logging, exfiltration of data on the page, XSRF, redirection to a phishing site, drive-by-downloads.
But as long as it is only redisplayed to the user who entered it and does not persist, it's not really an issue.
...
Only top voted, non community-wiki answers of a minimum length are eligible
