Tag Info

Hot answers tagged

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


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


4

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


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


3

What you describe is a wrong, spam practice but it does not cause other inconvenience over the spam aspect. Browsers allow JavaScript code initiated by a user click to add bookmarks in order to allow websites to propose friendly "Bookmark this site" buttons. However such functionality can be exploited in order to store unwanted bookmarks in visitors browser ...


3

This could conceivably be abused for HTML injection. Imagine if a user searched for the term waterfall</a><a href="http://maliciouslink.com">Click Here The </a> in the search term would terminate the mailto link, and then insert a second link with the words "Click Here". URL encoding will of course mitigate this problem. Also, make ...


2

You need to URL-encode SEARCHED_QUERY_HERE, otherwise if a user searches for &body=something, the body of the e-mail message will be set to something. Also, if you don't URL-encode it, if the user searches for a literal %20 (or similar) it will appear as a space in the message instead. This is not a security risk, though. The other, obvious risk is ...


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


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


2

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


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


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


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


1

ECB doesn't even make sense in the context of RSA. It's a mode of operation for symmetric ciphers like AES. More info: http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#ECB PKCS1Padding, however, does apply to RSA. And you're right - that likely means RSAES-PKCS1-V1_5. For the PHP side you can use phpseclib. eg. <?php ...



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