Skip to content

Enable MD033 rule #2382

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
MylesBorins merged 6 commits into from
Aug 23, 2019
Merged

Enable MD033 rule #2382

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
3ddd628
chore: Enable MD033/no-inline-html
nschonni Aug 10, 2019
0ef30ba
fix: Remove "ins" elements
nschonni Aug 10, 2019
66c9905
fix: Use Markdown blockquotes
nschonni Aug 10, 2019
c8e2357
fix: Escape "prot" for release log
nschonni Aug 10, 2019
7dd651f
fix: Replace multiple H1s
nschonni Aug 10, 2019
725348a
fix: Remove commented out "anonymous" tag
nschonni Aug 22, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 15 additions & 1 deletion .markdownlint.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,21 @@
"MD028": false,
"MD031": false,
"MD032": false,
"MD033": false,
"MD033": {
"allowed_elements": [
"a",
"br",
"hr",
"h2", "h3", "h4",
"figure", "figcaption", "img",
"ol", "ul", "li",
"div", "span", "p",
"table", "th", "tr", "td",
"code", "pre",
"i", "strong", "em", "b",
"sup"
]
},
"MD034": false,
"MD035": false,
"MD036": false,
Expand Down
219 changes: 117 additions & 102 deletions locale/en/blog/module/service-logging-in-json-with-bunyan.md
View file
Open in desktop

Large diffs are not rendered by default.

4 changes: 2 additions & 2 deletions locale/en/blog/release/v0.8.0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -383,5 +383,5 @@ fc07b475d943f7681e1904d6d7d666b41874a6fa x64/node.exe
75549cffab0c11107348a66ab0d94d4897bd6a27 x64/node.pdb
```

<ins>Edited by Tim Oxley to provide percentage differences in the
benchmarks.</ins>
**Edited by Tim Oxley to provide percentage differences in the
benchmarks.**
2 changes: 1 addition & 1 deletion locale/en/blog/uncategorized/evolving-the-node-js-brand.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ To echo <a href="https://nodejs.org/">Node</a>’s evolutionary nature, we have

<strong>Building a brand</strong>

We began exploring elements to express Node.js and jettisoned preconceived notions about what we thought Node should look like, and focused on what Node is: <strong>kinetic</strong>,<strong>connected</strong>, <strong>scalable</strong>, <strong>modular</strong>, <strong>mechanical</strong> and <strong>organic</strong>. Working with designer <a href="http://www.chrisglass.com">Chris Glass</a>, our explorations emphasized Node's dynamism and formed a visual language based on structure, relationships and interconnectedness.
We began exploring elements to express Node.js and jettisoned preconceived notions about what we thought Node should look like, and focused on what Node is: <strong>kinetic</strong>, <strong>connected</strong>, <strong>scalable</strong>, <strong>modular</strong>, <strong>mechanical</strong> and <strong>organic</strong>. Working with designer <a href="http://www.chrisglass.com">Chris Glass</a>, our explorations emphasized Node's dynamism and formed a visual language based on structure, relationships and interconnectedness.

<img class="alignnone size-full wp-image-184" title="grid" src="https://nodeblog.files.wordpress.com/2011/07/grid.png" alt="" width="520" height="178" />

Expand Down
80 changes: 41 additions & 39 deletions ...og/vulnerability/http-server-security-vulnerability-please-upgrade-to-0-6-17.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,42 +7,44 @@ category: vulnerability
slug: http-server-security-vulnerability-please-upgrade-to-0-6-17
layout: blog-post.hbs
---

<h2>tl;dr</h2>

<ul><li><p>A carefully crafted attack request can cause the contents of the HTTP parser's buffer to be appended to the attacking request's header, making it appear to come from the attacker. Since it is generally safe to echo back contents of a request, this can allow an attacker to get an otherwise correctly designed server to divulge information about other requests. It is theoretically possible that it could enable header-spoofing attacks, though such an attack has not been demonstrated.</li>
<li>Versions affected: All versions of the 0.5/0.6 branch prior to 0.6.17, and all versions of the 0.7 branch prior to 0.7.8. Versions in the 0.4 branch are not affected.</li>
<li>Fix: Upgrade to <a href="http://blog.nodejs.org/2012/05/04/version-0-6-17-stable/">v0.6.17</a>, or apply the fix in <a href="https://github.com/joyent/node/commit/c9a231d">c9a231d</a> to your system.</li></ul>

<h2>Details</h2>

<p>A few weeks ago, Matthew Daley found a security vulnerability in Node&#39;s HTTP implementation, and thankfully did the responsible thing and reported it to us via email. He explained it quite well, so I'll quote him here:</p>
<blockquote>
<p>There is a vulnerability in node&#39;s `http_parser` binding which allows information disclosure to a remote attacker:

</p>
<p>In node::StringPtr::Update, an attempt is made at an optimization on certain inputs (`node_http_parser.cc`, line 151). The intent is that if the current string pointer plus the current string size is equal to the incoming string pointer, the current string size is just increased to match, as the incoming string lies just beyond the current string pointer. However, the check to see whether or not this can be done is incorrect; &quot;size&quot; is used whereas &quot;size_&quot; should be used. Therefore, an attacker can call Update with a string of certain length and cause the current string to have other data appended to it. In the case of HTTP being parsed out of incoming socket data, this can be incoming data from other sockets.

</p>
<p>Normally node::StringPtr::Save, which is called after each execution of `http_parser`, would stop this from being exploitable as it converts strings to non-optimizable heap-based strings. However, this is not done to 0-length strings. An attacker can therefore exploit the mistake by making Update set a 0-length string, and then Update past its boundary, so long as it is done in one `http_parser` execution. This can be done with an HTTP header with empty value, followed by a continuation with a value of certain length.

</p>
<p>The <a href="https://gist.github.com/2628868">attached files</a> demonstrate the issue: </p>
<pre><code>$ ./node ~/stringptr-update-poc-server.js &amp;
[1] 11801
$ ~/stringptr-update-poc-client.py
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Wed, 18 Apr 2012 00:05:11 GMT
Connection: close
Transfer-Encoding: chunked

64
X header:
This is private data, perhaps an HTTP request with a Cookie in it.
0</code></pre>
</blockquote>
<p>The fix landed on <a href="https://github.com/joyent/node/commit/7b3fb22">7b3fb22</a> and <a href="https://github.com/joyent/node/commit/c9a231d">c9a231d</a>, for master and v0.6, respectively. The innocuous commit message does not give away the security implications, precisely because we wanted to get a fix out before making a big deal about it. </p>
<p>The first releases with the fix are v0.7.8 and 0.6.17. So now is a good time to make a big deal about it. </p>
<p>If you are using node version 0.6 in production, please upgrade to at least <a href="http://blog.nodejs.org/2012/05/04/version-0-6-17-stable/">v0.6.17</a>, or at least apply the fix in <a href="https://github.com/joyent/node/commit/c9a231d">c9a231d</a> to your system. (Version 0.6.17 also fixes some other important bugs, and is without doubt the most stable release of Node 0.6 to date, so it&#39;s a good idea to upgrade anyway.) </p>
<p>I&#39;m extremely grateful that Matthew took the time to report the problem to us with such an elegant explanation, and in such a way that we had a reasonable amount of time to fix the issue before making it public. </p>
## tl;dr

- A carefully crafted attack request can cause the contents of the HTTP parser's buffer to be appended to the attacking request's header, making it appear to come from the attacker. Since it is generally safe to echo back contents of a request, this can allow an attacker to get an otherwise correctly designed server to divulge information about other requests. It is theoretically possible that it could enable header-spoofing attacks, though such an attack has not been demonstrated.
- Versions affected: All versions of the 0.5/0.6 branch prior to 0.6.17, and all versions of the 0.7 branch prior to 0.7.8. Versions in the 0.4 branch are not affected.
- Fix: Upgrade to [v0.6.17](http://blog.nodejs.org/2012/05/04/version-0-6-17-stable/, or apply the fix in [c9a231d](https://github.com/joyent/node/commit/c9a231d) to your system.

## Details

A few weeks ago, Matthew Daley found a security vulnerability in Node&#39;s HTTP implementation, and thankfully did the responsible thing and reported it to us via email. He explained it quite well, so I'll quote him here:

> There is a vulnerability in node&#39;s `http_parser` binding which allows information disclosure to a remote attacker:
>
> In node::StringPtr::Update, an attempt is made at an optimization on certain inputs (`node_http_parser.cc`, line 151). The intent is that if the current string pointer plus the current string size is equal to the incoming string pointer, the current string size is just increased to match, as the incoming string lies just beyond the current string pointer. However, the check to see whether or not this can be done is incorrect; &quot;size&quot; is used whereas &quot;size_&quot; should be used. Therefore, an attacker can call Update with a string of certain length and cause the current string to have other data appended to it. In the case of HTTP being parsed out of incoming socket data, this can be incoming data from other sockets.
>
> Normally node::StringPtr::Save, which is called after each execution of `http_parser`, would stop this from being exploitable as it converts strings to non-optimizable heap-based strings. However, this is not done to 0-length strings. An attacker can therefore exploit the mistake by making Update set a 0-length string, and then Update past its boundary, so long as it is done in one `http_parser` execution. This can be done with an HTTP header with empty value, followed by a continuation with a value of certain length.
>
> The [attached files](https://gist.github.com/2628868) demonstrate the issue:
>
> ```
> $ ./node ~/stringptr-update-poc-server.js &amp;
> [1] 11801
> $ ~/stringptr-update-poc-client.py
> HTTP/1.1 200 OK
> Content-Type: text/plain
> Date: Wed, 18 Apr 2012 00:05:11 GMT
> Connection: close
> Transfer-Encoding: chunked
>
> 64
> X header:
> This is private data, perhaps an HTTP request with a Cookie in it.
> 0
> ```

The fix landed on [7b3fb22](https://github.com/joyent/node/commit/7b3fb22) and [c9a231d](https://github.com/joyent/node/commit/c9a231d), for master and v0.6, respectively. The innocuous commit message does not give away the security implications, precisely because we wanted to get a fix out before making a big deal about it.

The first releases with the fix are v0.7.8 and 0.6.17. So now is a good time to make a big deal about it.

If you are using node version 0.6 in production, please upgrade to at least [v0.6.17](http://blog.nodejs.org/2012/05/04/version-0-6-17-stable/), or at least apply the fix in [c9a231d](https://github.com/joyent/node/commit/c9a231d) to your system. (Version 0.6.17 also fixes some other important bugs, and is without doubt the most stable release of Node 0.6 to date, so it&#39;s a good idea to upgrade anyway.)

I&#39;m extremely grateful that Matthew took the time to report the problem to us with such an elegant explanation, and in such a way that we had a reasonable amount of time to fix the issue before making it public.
25 changes: 0 additions & 25 deletions locale/ja/docs/guides/buffer-constructor-deprecation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,31 +48,6 @@ exceptions).

それにより自身のコードの中ですべての潜在的に危険な箇所が分かるでしょう (とてもありそうにない例外を除いて)。

<!--
### Finding problematic bits of code using Node.js 8

If you’re using Node.js ≥ 8.0.0 (which is recommended), Node.js exposes multiple options that help with finding the relevant pieces of code:

- `--trace-warnings` will make Node.js show a stack trace for this warning and other warnings that are printed by Node.js.
- `--trace-deprecation` does the same thing, but only for deprecation warnings.
- `--pending-deprecation` will show more types of deprecation warnings. In particular, it will show the `Buffer()` deprecation warning, even on Node.js 8.

You can set these flags using environment variables:

```bash
$ export NODE_OPTIONS='--trace-warnings --pending-deprecation'
$ cat example.js
'use strict';
const foo = new Buffer('foo');
$ node example.js
(node:7147) [DEP0005] DeprecationWarning: The Buffer() and new Buffer() constructors are not recommended for use due to security and usability concerns. Please use the new Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() construction methods instead.
at showFlaggedDeprecation (buffer.js:127:13)
at new Buffer (buffer.js:148:3)
at Object.<anonymous> (/path/to/example.js:2:13)
[... more stack trace lines ...]
```

-->
### Node.js 8 を使用して問題のあるコードを見つける

Node.js ≥ 8.0.0 (これが推奨されています) を使用している場合、Node.js は関連するコードを見つけるのに役立つ複数のオプションを公開します。
Expand Down