Errata

Several times in chapter 4 the search engine “-“ operator (minus, as in “exclude”) is typed as “--“ as if it was the prefix to a command line argument.

The language in this section is imprecise in ways that are misleading.

Leading up to the example code there are two statements about what is done with the list of possible subdomains: “we fire off a request to <subdomain-guess>.mega-bank.com” and “pinging each time to detect if the subdomain is live”.

The actual implementation does not make any kind of request to the subdomain (including sending a ping). Instead it sends a request to a nameserver to resolve the domain.

Figure 3-6 is a screenshot of a browser’s JavaScript console session demonstrating the use of localStorage.

localStorage can only store strings, but the example shows an object being stored. The object is converted to the useless string “[Object object]”, which is evident in the following lines showing the contents of localStorage and demonstrating retrieval from localStorage.

He said that web sockets permit client-client communication. I'm skeptical that web sockets can provide *direct* client-client communication, especially if there is a NAT in the way. I feel like you would normally have two browsers connected to a server, so the server is really in the middle.

It says "Underscore and Lodash expose globals using the underscore symbol $..." I do believe the symbol is `_`.

There are 2 mistakes in the way the `send` function gets the data from html resulting `message` variable being always an empty string and `target` variable being always `undefined`. See the code below, I included original code from the book along with fixes.

const send = function() {
const message = document.querySelector('#send').value; // <-- incorrect
const target = document.querySelector('#target').value; // <-- incorrect

const messageFixed = document.querySelector('.input').value; // <-- correct
const targetFixed = document.querySelector('#target').innerText; // <-- correct

https://jsbin.com/ciwotahoni/edit?html,console,output

It says, "A reflected XSS affects the code of the client in the browser directly without relying on a server to relay a message to be rendered with a script to be executed."

This is sometimes true, but not always. For instance, you might have a search field that does a GET to the server, and then the server outputs a search results page containing the unescaped search query. This is still coming from the server. It's just not getting stored in the DB.

See also 125.1.

It says, "Because DOM XSS never touches a server, it is nearly impossible to detect with static analysis tools or any other type of popular scanner." I'm skeptical of this statement. Static analysis tools don't care if some other part of your codebase is or is not talking to the server. My point is that whether or not your code talks to a server is orthogonal. If the static analysis tool is wary of you using a sink with some dynamic data, it doesn't matter where you got that data.

Your use of document.write() in this example doesn't make sense because it'd probably write to the wrong place on the page. Hence, this code could work in theory, but I've never seen it work like this in practice. In practice, you'd use someNode.innerHTML.

The text is skipping over the need for proper CORS headers when using an XHR to talk to a site other than the origin server.

If you POST a form in order to do a CSRF attack, that doesn't require user interaction. You can use JavaScript to submit the form.

The text suggests that HTML is a subset of XML. That may have been true for XHTML, but it's certainly not true with HTML5. There are several features in HTML5 that when used cause the content to not be valid XML.

There is a call to alert() that is missing double quotes around the string.

It says "An SQL string is escaped in an HTTP payload..." This needs to be reworded because it confusing and misleading. It's not about the fact that it's escaped in an HTTP payload. I mean, the user could have just typed it into a simple form field. Rather, the user used some unexpected characters that break the SQL string that the developer was creating. For instance, the user could use:

' and true; drop tables...; --

It talks about the 1=1 trick. However, let's suppose the query is:

query = 'select * from users where id = ' + user_id;

That would result in:

query = 'select * from users where id = 1 = 1';

That probably wouldn't work. You probably need something like:

user_id = '0 or 1 = 1';

There's a query:

select * from users where user = 123abd;

I suspect you need to put that value in quotes.

In the code `const res = await compressImage()`, you're overwriting the res variable that was originally set in `function(req, res)` on p. 152.9. This would prevent the later code, `return res.status(200)` from executing correctly.

I think you're using the wrong path to the image in the code. The image is actually in the /compressed/ directory.

It says, "rather than performing unintended actions against a CLI or interpreter, we are performing unintended actions against an OS."

I'd reword this. You're talking about injecting stuff into bash. bash both has a CLI and is an interpreter. You're not really directly attacking an OS (i.e. by making system calls). You really are just attacking an interpreter, i.e. bash, which happens to itself make system calls into the OS.

It says:

exec(rm ...

You're missing the quotes.

You wrote "264 bits of data". I think you mean "256 bits of data".

By the way, I think your password-handling recommendations are a bit dated. "Cryptographic Right Answers" suggests:

"In order of preference, use scrypt, argon2, bcrypt, and then if nothing else is available PBKDF2."

You said that "2FA eliminates remote logins to your web applications that were not initiated by the owner of the account." I'd say it helps, but it doesn't fully eliminate this problem. There's still the attack where you convince the user to log into a copycat site. The copycat site can ask for the user's password as well as 2FA and then use those to log into the real site.

Just because you've switched from GET to POST doesn't mean you've alleviated CSRF.

This code doesn't make sense. 'hi' is a string. But, running JSON.parse('hi') would raise an exception.

It says:

Let's assume your sanitizer blocks single and double quotes as well as script tags. You could still run into this issue:

a href...

Notice that in your code, you used double quotes, but you said those were blocked :-/

The text suggests that merely embedding a script tag in a URL will cause the script tag to execute when you load the URL. I didn't think that would work, and in fact, in my testing, it doesn't.

It says:

if (!origin || referrer) { return false; }

It should probably say:

if (!(origin || referrer)) { return false; }

You wrote:

isValid = validLocations.includes(referer)...

The referer might contain a path as well, and that would break the code.

Also, consider the else branch. You might not even get a referer with a GET if the user just types in the URL manually.

You wrote:

your users will be able to feel more comfortable entering your web application from other origins

This doesn't make sense. They don't know enough to feel uncomfortable, and with CSRF, it's not like they're *choosing* to interact with a domain from another domain.

It says that schema validation is not supported with JSON. However, there are tools and libraries to validate JSON. See JSON Schema.

It says:

JSON, a format that simply stores key/value pairs in a string-based format.

I think this is not correct. For instance the following is valid JSON, but it's not a key/value pair:

5

It talks about sockets when it should really talk about WebSockets.

The text implies that PDF is an XML format. Although PDFs can be converted to XML, PDFs themselves are not XML.