For 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].
* 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?
This smells of an AI generated book. A bunch of recipes, no personal input from the writer, no personal experience or advice or insight. A bunch of howto's with massive consistency in presentation and length. Highly unusual for human produced content.
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 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???
It cannot. Even if you use JavaScript to try to limit what the browser allows the user to do, anyone can send an HTTP request to your server with absolutely arbitrary content. Only your server can determine if the input is reasonable and legal.
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.
Extra round trips -- yes, the page I send back to the user will not be 100% waste since that page gets to have another collection of ads. For the server load and Internet data rate, good news would be when need more of those two!
In a sense, the round trip can help make the user interface (UI) easier for the user: The dialog can be really explicit and easy for nearly every candidate user in the world to understand immediately effortlessly. In contrast, an active UI based on a lot of JavaScript will look unique and need some thought, trials, and experience by the user. My UI is built with links, single line text boxes, and push buttons -- ancient controls billions of people understand. And the Web pages are in a hierarchy that people can understand easily because it is natural.
I'd likely prefer to minimize the JavaScript I send to a user and have my main software run only on the server side -- all in one place instead of distributed around!
You mentioned the issue of quality for software from someone else: Reasons I'm going with Microsoft are that (a) they actually do know how to write and document software tools and (b) everything my Web site is asking of those tools the tools have long since done successfully at thousands of Web sites.
While I've done a lot of programming, etc., this is my first Web site. Thanks!
> 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.
Is there some way to stop browsers (and browser extensions) from injecting JavaScript into a website? I don't think there is, but wanted to ask. I normally set script-src 'none' in my Content Security Policies (HTTP header and HTML meta tag) because I do not use JavaScript, but that does not stop an extension from removing that header/tag and injecting JS.
Other sites, yeah... extensions, not so much... extensions are things the user wants (or at least seems to want) to include. Poorly written extensions aren't great but it's a user issue. Could you imagine, for example, the NYT being able to disable your ad blocker extension?
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.com/rajamsrgit/JavaScriptSecurityCookbook/blo...
reply