Live data from Hacker News

JavaScript Security Cookbook

github.com

1–10 of 18 posts

Re: JavaScript Security Cookbook

#2
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].

[0] https://github.com/rajamsrgit/JavaScriptSecurityCookbook/blo...

Re: JavaScript Security Cookbook

#3

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

Re: JavaScript Security Cookbook

#4
post #3

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

A few others that jump out to me:

* 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

#5
Help!!

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

Explanations???

Re: JavaScript Security Cookbook

#6
post #5

Help!! 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

#7
post #5

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

Thanks!

Re: JavaScript Security Cookbook

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

Does anyone know if this is possible?

Re: JavaScript Security Cookbook

#10
post #5

Help!! 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…

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.

Post reply on HN