Welcome Guest, Not a member yet? Register   Sign In
Thoughts
#1

Hi Team,

This is my first post, I stay in Florida USA. Thanks for the free registration to the forum.

Question: How do you guys feel about htmlpurify? A few posts in this forum regarding htmlpurify are too old.

Generally, I've only used htmlpurufy to upload data to the database and thats it. Can you recommend any more security practices regarding user input?

Its my first CodeIgniter application.
Reply
#2

(This post was last modified: 12-13-2015, 08:32 PM by solidcodes.)

Well we are in the same boat right now.
I'm also trying to understand what's the safest way for WYSIWYG editor like tynyMCE
and end up reading htmlpurifier too but I came across this article.
http://www.dereuromark.de/2014/07/16/htm...or-bbcode/

So I'm going to use 'markdown'. This is the same editor tool currenly being use in github.

Hope it helps
No SEO spam
Reply
#3

(12-13-2015, 08:08 PM)solidcodes Wrote: Well we are in the same boat right now.
I'm also trying to understand what's the safest way for WYSIWYG editor like tynyMCE
and end up reading htmlpurifier too but I came across this article.
http://www.dereuromark.de/2014/07/16/htm...or-bbcode/

So I'm going to use 'markdown'. This is the same editor tool currenly being  use in github.

Hope it helps

Thanks for the interesting link and then a sublink to tinymce. It is interesting this company has this page haha:
https://www.tinymce.com/docs/advanced/security/

You see their recommendation? :-P
Reply
#4

Great question BTW.

I too am in a situation where I have a site with a WYSIWYG going live soon and I don't know what to do either. In fact I had decided not to use HTML purifier, but might back track on that a bit, as on rereading it is actually looking very good.

For now I scan myself for common variants of things I do not want included. But that turned out to be a hopeless task as I am nowhere near as clever as the people trying to break the site (or as stupid as some of my users).

So, following your post and subsequent 'rethink' I am going to use html purifier too, but in the meantime just wanted to share that I too have this issue and have no idea what to do about it, as in this instance I don't see how I can not use a WYSIWYG solution. I think HTML purifier is the best there is at the moment.

Best wishes,

Paul

PS Which WYSIWIG did you choose?
Reply
#5

(12-14-2015, 08:54 AM)PaulD Wrote: Great question BTW.

I too am in a situation where I have a site with a WYSIWYG going live soon and I don't know what to do either. In fact I had decided not to use HTML purifier, but might back track on that a bit, as on rereading it is actually looking very good.

For now I scan myself for common variants of things I do not want included. But that turned out to be a hopeless task as I am nowhere near as clever as the people trying to break the site (or as stupid as some of my users).

So, following your post and subsequent 'rethink' I am going to use html purifier too, but in the meantime just wanted to share that I too have this issue and have no idea what to do about it, as in this instance I don't see how I can not use a WYSIWYG solution. I think HTML purifier is the best there is at the moment.

Best wishes,

Paul

PS Which WYSIWIG did you choose?

I see. If WYSIWYG is mandatory in your app, I'm not sure I can be much of a guide.
In my scenario, I was considering a 90's textarea box while cleaning user input AND converting newlines into html p tags for SEO reasons.

In other words, I'm choosing to ignore user styles but preserving paragraphs.
Reply
#6

When getting any data in from a user, you should filter/sanitize the data depending on where it's going. PHP provides the filter_var and filter_input that can help with that. However, it seems to all depend on how well you use the filter types (FILTER_SANITIZE_STRING), etc. That helps clean the text up. HTMLPurifier is great at that also, and even helps close tags, which is a good defense.

Next, you would need to escape the text before sending it to the database using $this->db->escape() or one of the Query Builder commands that will auto-escape it for you. That makes sure it doesn't do anything bad during the save or retrieval process from the database.

Finally, you need to escape the data for use within the HTML itself, on display. This can be done with something like htmlspecialchars($message) that tries to encode the special HTML characters that can be used to do XSS attacks and the like into safe HTML characters. This step gets more complicated as you get more advanced in your skills and knowledge, because you start to realize there are different types of escaping that need to be done based on whether it's in your HTML body, or an attribute tag, or in javascript code, or a URL, or some combination of the above that needs multiple types of escaping. It's one of the hardest parts to do 100% correctly. The best tool I've found for doing that is Zend's Escaper. All of that said, though, in your case, doing htmlspecialchars() when you display it to the user is a great start.

I would start by trying filter_var first on the input. If that takes too much out, then you might need to do something manually using strip_tags to remove any tags that you don't want while white-listing tags you do want to allow.

Or, yes, disable all HTML/CSS in the input and use something like Markdown. Smile
Reply




Theme © iAndrew 2016 - Forum software by © MyBB