Prevent form against inadequate use

[tripu]

• noindex
• nofollow
• Dodge crawlers
• CAPTCHA?

[tripu]

cf https://blog.risingstack.com/node-js-security-checklist/

[iherman]

@tripu I went through the tests, so far as I could understand them; here is the checklist so far. There are some open issues for which you may have an answer.

• [X] Configuration Management
  • [X] Security HTTP Headers: not applicable. Seems to be relevant for server side implementations; scribejs does not operate as a server.
  • [X] Sensitive Data on the Client Side: check. The only sensitive data may be the github credential; that is not in the code.
• [X] Authentication
  • [X] Brute Force Protection: not applicable. Seems to be relevant for server side implementations; scribejs does not operate as a server.
• [ ] Session Management
  • [X] Cookie Flags: not applicable, no cookies are used.
  • [X] Cookie scope: not applicable, no cookies are used.
  • [ ] CSRF: I am not sure I understand, but does not seem to be applicable that is server specific

• [ ] Data validation

  • [ ] XSS: Sanitize user input: that may be necessary for the data received via the HTTP POST that is issued when the form is submitted. Not sure how and what to do about it: how do I ensure that the input is proper text without any executable? Or is it necessary to check? There is no eval or similar in the program.

    Is it necessary to check whether the input is not too large? Ie, that it would not override some buffers? Or do browsers have protections for this?

  • [X] SQL Injection: not applicable, there is no underlying database handling.

  • [x] Command Injection: again, sanitize user input, mostly URL-s. I am not sure what is to be done.

• [ ] Secure transmission. This is mostly around the usage and the check of HTTPS; isn't this a matter of the server setup at lab.w3.org?
• [ ] Denial of service
  • [ ] Account lockout: is there a way to avoid a DoS type attack on a CGI script target? I.e., to avoid zillions of such calls? I am not sure that is something that script itself can/should do…
  • [X] Regular Expressions: the input, or any part of the script, is not using regular expressions. However, the s/.../.../ feature uses regular expressions internally, by turning the first string into a regex (this is used to ensure that all occurrences in a line of the match are changed). The safe-check approach has been implemented for this (as part of PR #33)
• [X] Error handling
  • [X] Error codes, stack traces: checked the catch or throw calls. At some place, potentially, secret information like the gh token could spill to the public; I have obfuscated those (as part of PR #33)
• [X] NPM
  • [X] NSP: I checked the package with NSP; no vulnerability found.

I also do not know whether the usage of local storage in the browser has separate vulnerabilities.

[tripu]

Good work, @iherman! I'll review your PR very soon.

[tripu]

(You see? You're beginning to love Node.js development… ;)

[iherman]

Good work, @iherman! I'll review your PR very soon.

There are, actually, only very few changes in the PR. But there are a number of questions in the list of items for which I do not really have an answer...

[iherman]

Added some changes on URL sanitation, see comment in #33.

[iherman]

I guess this issue is also moot with the disappearance of the CGI interface