Tag Info

New answers tagged

1

You're lucky: it's Windows-specific. First, I took the code, and went to jsbeautifier.org to beautify it: var stroke = "5556515E070B0A1005071024120D171005011C140116100D17014A0A0110"; function do193() { return ',"h'; }; function do112() { return ') { '; }; function do127() { return 'r xa'; }; function do88() { return '= 0;'; }; function ...


-1

Ive seen alot of this script on osdir.com I would delete and reinstall browsers or spend alot of time reading up each function and still delete browser :) sorry couldnt give you answer


2

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

This sounds a lot like ad-injection software installed by accident. This could be something like a Chrome extension or something bundled along with a download. Google recently did a study on the matter, and they state that they "received more than 100,000 user complaints about them in Chrome since the beginning of 2015", making this a realistic scenario for ...


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


9

To show you it is easy to de-obfuscate your code, and therefore kind of useless to obfuscate it in the first place, I will present you how I did to de-obfuscate it in a quick and dirty fashion: I took your code, and replaced the first "eval" by "console.log". This gave me another (smaller) code starting with "eval". So I repeated this process 9 times, as ...


5

I think your 'testing' is redundant. Obfuscation is not encryption and it is completely possible to de-obfuscate even if it takes manual investigation and a lot of patience. There are many tools out there to assist and there is no logical reason why this example can't be reduced to a simpler chunk of code relatively quickly. Anyone's effort to decode this ...


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


0

Answer Updated : You need the eval to convert you coded javascript to string because otherwise the browser could not take it in consideration as an instruction. When you look at the code used on http://www.jsfuck.com/ the "run function" use eval no matter what $("run").onclick = function(){ value = eval($("output").value); if (!$("eval").checked){ ...


1

XSS only happens when data is output. In your code sample you are setting the variable myhash to the hash value in the address bar. As your code doesn't contain any sinks and your variable is not output, the above code, in isolation, is not vulnerable. However, to check for XSS vulnerabilities you need to focus on output to your application rather than ...


0

Yes, any website can make requests to localhost (or any other host). They have to do so indirectly, via your web browser. They can't connect directly. And you have to visit a page on their site. They can't initiate it on their own. Due to the Same-Origin Policy they cannot read any useful info from your site. However they can still POST anything they ...


1

You can use window.location.protocol to check what protocol is in use. But the attacker can deliver page without this tag, so you will need a check for existance of this script in page. Personally, I would use HSTS for eliminating this type of attack, not by checking the protocol.


1

To answer the question: Yes a website can make an HTTP request to localhost. It will not break cross domain policy, because the request will not cross domains. It will stay local. One way to avoid cross domain policies, it to get the target victim, to make the HTTP request themselves. Thus the request never crosses domains. To help you understand the ...


3

This works for me: <html> <img src=1 ...


0

PCI standards exist for a reason. While the process of achieving that level of security may be arduous, it is necessary to protect your client's data. Let's be clear about that; it's not just your data, it is data that your clients have entrusted to your care, and if you fail to secure it using reasonable best practice, your company is opening itself to ...


3

SSL/TLS is the encryption layer between browser and server. As long as you have properly configured your SSL/TLS on the server, any additional javascript type encryption is redundant. If you are trying to create a secure application, and your team does not understand what SSL/TLS does, you might want to consider bringing in a security consultant to help ...


1

From the OP's comments it doesn't sound like this would be useful to them, however, it may be useful to others. It's possible to usefully encrypt information client side, but the use cases are few and far between. Example use case: The user needs to work on confidential (as least by their judgment) documents which must be stored locally (perhaps to lower ...


13

JavaScript cryptography is not a good idea JavaScript cryptography is not bad per se, it's just ineffective against most commonly considered threats. If you consider a man-in-the-middle (MITM) to be a threat then SSL/TLS is a much more effective control as otherwise the attacker could substitute the JavaScript for a version which doesn't use ...


2

Have you think to use SSL/TLS on server side. So the data will traverse over secured channel. And on server side later you can encrypt ti and store it in such form in the database



Top 50 recent answers are included