Tag Info

Hot answers tagged

4

According to your question Chrome was loading a plain HTTP favicon in a HTTPS page without any browser warning. Interesting. Redirecting to a plain HTTP website is not a vulnerability in itself. However, it is a security flaw if the redirect is accidental and you want your users to remain on a secure, trusted channel to your site. Script content will not ...


4

Avoiding attacks on your site You need to validate that the string you received is valid. Remember this principle: you must white-list acceptable strings rather than black-list unacceptable ones. Ensure that the string is a syntactically-correct and escaped URL. Escaping the whole URL avoids it containing " or > which could break your site's syntax. ...


3

This is not to prevent double quotes, single quotes or spaces from breaking out of the attribute context, as this is covered by "Aggressive HTML Entity Encoding". For background, an attack like this is possible: <body background="javascript:alert('XSS')"> For id and name, these attributes are frequently used as reference points in the DOM. If an ...


2

There's no such thing as special characters. It all depends on the context that input is used within your application. Protecting against SQLi and XSS is great, however if then input is then to be used in an operating system shell call it does you no good. Always encode or sanitize when the data is used - leave this as late as possible. For example when ...


1

You probably need to google and read about XSS but here's a quick intro. Cross-site scripting is an attack where a hostile site, let's call it H, attacks your site S. H has on it a link to S that has malicious code in it that has been designed to provide the attacker with some benefit (eg: useful information or perform an action). This will likely only work ...


1

Yes, it can be bypassed. First, many filters that attempt to remove <script> tags do so in a way that is easily defeated. For example, they may improperly handle input like <scr<script>ipt>. But even when implemented "properly", that is not sufficient, because <script> tags are not required to execute Javascript on a page: event ...


1

As @Gumbo has said, CRLF are properly encoded with %0d%0a in the resulting URL, as you may see. If it had set headers as you had passed as parameters, you would have seen those headers separately. You may try different encoding instead, like %E5%98%8A%E5%98%8D :) The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting ...


1

There is indeed a vulnerability, because as you observed, an attacker could intercept the traffic on the unsecured line and change it. The reason your script didn't execute is that this came in the favicon, and Chrome (apparently) does not execute scripts in the favicon. To exploit this, you would have to get Chrome to execute the code in the favicion. ...


1

I suppose if the tracker is using HTML/javascript to show content then yes - it's possible. If there isn't any XSS protection in place, someone could include the following: myfile.txt<script>alert(1);</script> in a file name or some other field that is rendered and it could potentially execute.



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