You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What steps will reproduce the problem?
1. Reference MarkdownSharp.dll in a web project.
2. Server.HtmlEncode(userInput)
3. markdown.Transform(encodedUserInput)
4. You will notice that the already encoded text gets re-encoded within code
tags.
What is the expected output?
I would expect to be able to encode user input so that it can be safely stored
in the database without having to worry about it getting pulled out and
rendered incorrectly, at which point users visiting the site could become
vulnerable to XSS attacks. I would then expect MarkdownSharp not to re-encode
the values in the code blocks since they are already encoded, or at least offer
a boolean switch to disable re-encoding of tags in code blocks.
What do you see instead?
MarkdownSharp re-encodes the code within the code tags that are rendered to the
client.
Please provide any additional information below.
I have fixed the issue myself and added an option to the MarkdownSharp source
that will disable the encoding of code blocks. I have attached the modified
Markdown.cs file to this issue. Scan the file for _encodeCodeBlocks and you
will find every area that I made changes to as that is the boolean option I
added to change the behavior.
If this ever opens up in the future for contribution I would be interested.
Original issue reported on code.google.com by Chevex...@gmail.com on 17 Mar 2011 at 8:17
Markdown allows arbitray HTML, so HtmlEncode before the transforming makes
hardly any sense, whether in code blocks or not. For instance, if a user enters
"bold" (which is valid in Markdown), HtmlEncoding would turn that into
"<b>bold</b>", which is obviously not the desired result.
See my answer at
http://meta.stackoverflow.com/questions/95821/markdownsharp-not-a-complete-rip-f
rom-stack-overflow/95861#95861 for more.
Original comment by ahp...@googlemail.com on 12 Oct 2011 at 2:43
Original issue reported on code.google.com by
Chevex...@gmail.com
on 17 Mar 2011 at 8:17Attachments:
The text was updated successfully, but these errors were encountered: