4 ms·

Well done :) | Just a note that NodeBB recently switched away from chjj/marked to jonschlinkert/remarkable due to its more robust API and better security (at le

Well done :) | Just a note that NodeBB recently switched away from chjj/marked to jonschlinkert/remarkable due to its more robust API and better security (at least from the limited tests we've run)

riffraff 12y ago
how is the security better? Is there a "safe markdown" test suite? EDIT: a ton of projects allow users to write markdown, but markdown allows, for example, raw html, which means letting a user input "full markdown" means leaving a gaping security hole. The CommonMark spec does not seem to consider the issue at all, but it seems like it should.
- eksith 12y ago
  All user input should go through some manner of filter regardless of the presented form. After all, it doesn't take too much effort to send raw post data without loading the page at all.
  - riffraff 12y ago
    I disagree, but maybe I am not understanding what you mean. If the presented form is "plain text" then encoding all html tags is an effective choice, if the presented form is "rich text" than tag/attribute whitelisting is necessary and you need to strip "bad stuff". The choice of presentation, combined with the choice of who is inputting the data, also poses problems in the UX, i.e. if you use a JS markdown editor in the browser and process data in python on the server stripping HTML than the user sees something going in and something else going out. A common standard of how to do safe markdown would help.
    - eksith 12y ago
      By filter, I meant server-side sanitization. Stripping "bad stuff" as you put it should be mandatory regardless. Someone can simply craft a raw post to the "action" URL of the form (the handler) without loading the page at all. As for client-side, the user has an expectation that what was entered into the form will be the end result, but this expectation is easy to meet for a vast majority of users. The edge cases tend to be solved most of the time with a live preview that also closely matches the server-side stripping of invalid/malformed content. When no JS is available/enabled, a preview button before final submission (a la Slashdot) is usually a good idea.
      - riffraff 12y ago
        > Stripping "bad stuff" as you put it should be mandatory regardless. Someone can simply craft a raw post to the "action" URL of the form (the handler) without loading the page at all. The second sentence is irrelevant, I am not assuming javascript checks, I already know user input is untrusted. But the first is, AFAICT, wrong: If I escape correctly all user input before using it, I don't need to strip anything (unless I want to let some HTML through). If you think escaping input is not enough, could you give me an example?

Well done :) | Just a note that NodeBB recently switched away from chjj/marked to jonschlinkert/remarkable due to its more robust API and better security (at least from the limited tests we've run)

riffraff 12y ago

how is the security better? Is there a "safe markdown" test suite? EDIT: a ton of projects allow users to write markdown, but markdown allows, for example, raw html, which means letting a user input "full markdown" means leaving a gaping security hole. The CommonMark spec does not seem to consider the issue at all, but it seems like it should.

eksith 12y ago
All user input should go through some manner of filter regardless of the presented form. After all, it doesn't take too much effort to send raw post data without loading the page at all.
- riffraff 12y ago
  I disagree, but maybe I am not understanding what you mean. If the presented form is "plain text" then encoding all html tags is an effective choice, if the presented form is "rich text" than tag/attribute whitelisting is necessary and you need to strip "bad stuff". The choice of presentation, combined with the choice of who is inputting the data, also poses problems in the UX, i.e. if you use a JS markdown editor in the browser and process data in python on the server stripping HTML than the user sees something going in and something else going out. A common standard of how to do safe markdown would help.
  - eksith 12y ago
    By filter, I meant server-side sanitization. Stripping "bad stuff" as you put it should be mandatory regardless. Someone can simply craft a raw post to the "action" URL of the form (the handler) without loading the page at all. As for client-side, the user has an expectation that what was entered into the form will be the end result, but this expectation is easy to meet for a vast majority of users. The edge cases tend to be solved most of the time with a live preview that also closely matches the server-side stripping of invalid/malformed content. When no JS is available/enabled, a preview button before final submission (a la Slashdot) is usually a good idea.
    - riffraff 12y ago
      > Stripping "bad stuff" as you put it should be mandatory regardless. Someone can simply craft a raw post to the "action" URL of the form (the handler) without loading the page at all. The second sentence is irrelevant, I am not assuming javascript checks, I already know user input is untrusted. But the first is, AFAICT, wrong: If I escape correctly all user input before using it, I don't need to strip anything (unless I want to let some HTML through). If you think escaping input is not enough, could you give me an example?