JavaScript Security Cookbook
github.com
JavaScript Security Cookbook
1–10 of 18 posts
Re: JavaScript Security Cookbook
#2One example for OP: you should not be representing yourself as a security expert if you're recommending hashing passwords using SHA-256 in the browser [0].
[0] https://github.com/rajamsrgit/JavaScriptSecurityCookbook/blo...
Re: JavaScript Security Cookbook
#3For anyone thinking of using this, at least a few of these examples are fundamentally broken. There may still be useful info here, but as-is it is dangerous to advertise this to new developers who aren't able to discern the good from the bad. One example for OP: you should not be representing yourself as a security expert if you're recommending hashing passwords using SHA-256 in the browser [0]. [0] https://github.co…
Do you have suggestions for alternative books dealing with similar topic?
Context: Noob in JS security, but know a decent amount of JS + building apps.
Re: JavaScript Security Cookbook
#4For anyone thinking of using this, at least a few of these examples are fundamentally broken. There may still be useful info here, but as-is it is dangerous to advertise this to new developers who aren't able to discern the good from the bad. One example for OP: you should not be representing yourself as a security expert if you're recommending hashing passwords using SHA-256 in the browser [0]. [0] https://github.co…
Are there other glaring mistakes in this book frequently ? Do you have suggestions for alternative books dealing with similar topic? Context: Noob in JS security, but know a decent amount of JS + building apps.
* 04-AntiForgeryToken would not provide any actual protection against CSRF (there are a few ways to do it, but all at minimum require 1) the token to be generated by the server and 2) a way for the server to compare against a known good value, either from its session DB or by "double-submitting" the token [0]).
* 18-SecureWebStorage encrypts the value without including an authentication tag, meaning it can likely be fully decrypted or modified by the user (lookup a Vaudenay attack or try out https://cryptopals.com/ if you're curious there)
Those are the ones I have specific experience with and looked at first, so maybe the more frontend-oriented examples are better?
[0] https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
Re: JavaScript Security Cookbook
#5My Web site runs on Windows. Nearly all the code is in Visual Basic.NET (VB) with some code in C accessed via Platform Invoke.
For building the Web pages there is use of ASP.NET (active server pages). There is some use of ADO.NET (ActiveX Data Objects) for operations on relational database (currently SQL Server).
What is sent to a user is just some HTML code with, optionally, a little JavaScript (JS) code written for me by ASP.NET.
So, the bytes my Web site sends go to the user's Web browser which does the defined things with the HTML and JS in ways that are not a security threat to the user's computer.
The user reads what their browser displays and types, clicks, and returns data to my Web server and VB software.
Then my VB software checks the data returned for reasonable and legal values. I am assuming that a user might enter data that needs these checks -- user typing errors, ..., malicious user.
It appears that the code in the JavaScript Security Cookbook (JSC) is intended to be sent to the user along with my HTML and JS code so that the JSC code running in the user Web browser can, e.g., do the checking for reasonable and legal values.
Question: How can the JSC code running in the user's computer protect my Web server from dangerous data sent by a malicious user? That is, it would seem that both in principle and in practice a malicious user could have their computer send my Web server any bytes at all and that the JSC code would be no protection for my server???
Explanations???
Re: JavaScript Security Cookbook
#6Help!! My Web site runs on Windows. Nearly all the code is in Visual Basic.NET (VB) with some code in C accessed via Platform Invoke. For building the Web pages there is use of ASP.NET (active server pages). There is some use of ADO.NET (ActiveX Data Objects) for operations on relational database (currently SQL Server). What is sent to a user is just some HTML code with, optionally, a little JavaScript (JS) code writ…
Correct, you protect the server on the server, but many servers run on javascript.
Disclaimer: I have not read the book and don't know if it's any good.
Re: JavaScript Security Cookbook
#7Help!! My Web site runs on Windows. Nearly all the code is in Visual Basic.NET (VB) with some code in C accessed via Platform Invoke. For building the Web pages there is use of ASP.NET (active server pages). There is some use of ADO.NET (ActiveX Data Objects) for operations on relational database (currently SQL Server). What is sent to a user is just some HTML code with, optionally, a little JavaScript (JS) code writ…
> That is, it would seem that both in principle and in practice a malicious user could have their computer send my Web server any bytes at all and that the JSC code would be no protection for my server??? Correct, you protect the server on the server, but many servers run on javascript. Disclaimer: I have not read the book and don't know if it's any good.
Re: JavaScript Security Cookbook
#8Re: JavaScript Security Cookbook
#9Does anyone know if this is possible?
Re: JavaScript Security Cookbook
#10Help!! My Web site runs on Windows. Nearly all the code is in Visual Basic.NET (VB) with some code in C accessed via Platform Invoke. For building the Web pages there is use of ASP.NET (active server pages). There is some use of ADO.NET (ActiveX Data Objects) for operations on relational database (currently SQL Server). What is sent to a user is just some HTML code with, optionally, a little JavaScript (JS) code writ…
However, sticking some extra protection on client-side can help users avoid accidentally sending bad data, or can help save a round trip to the server to find out if some data is going to be accepted or not.
I am not normally the kind of person who would criticise someone's hard work, but the vast majority of these 'recipes' contain significant flaws, or do essentially nothing, and are misleading at best.