If you use tinymce, does that mean you have to handle the parsing of the HTML on the postback (when saving the data to the db)?
i.e. you have to parse the output and make sure no hacky script was posted back or can you have tinymce convert the html into a safe markup?
You can't ever rely on the client to make sure that the content it posts to your server is safe.
Its much too easy for a potential attacker to disable those client-side measures and submit any dangerous content that he wants to.
Therefore you will always have to check your content on the server side, no matter what editor you use in the browser.
Yes, always!!! Just think if they turn off the editor or don't have javascript enabled.
We use the 'valid elements' check to ensure we only get standard HTML out of the editor. No scripts, no events on tags pasted in (e.g anchor tags with onclick events). Just boring, ordinary HTML.
http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/valid_elements
Related
I'm using the free JS plugin from tinymce and interested in preventing an HTML injection with the tinymce text editor.
I've added this property to the INIT:
invalid_elements: 'script' (just for this example)
However nothing happens. The editor still "accepts" the script tag and pass it on.
I looked at https://www.tiny.cloud/docs/tinymce/6/content-filtering/#invalid_elements and it should work but I don't see any change once it's added.
Am I doing something wrong?
Is there a way to limit some HTML elements with this editor?
Any other tips on how to use that editor and prevent the malicious HTML..?
TinyMCE certainly has a variety of configuration options to help you control what content is created in the editor but you can never assume that data provided to you client side is "clean" or "safe". Nefarious people can bypass your front end and all of its validation if their goal is to cause harm to your system.
You should always configure your front end appropriately. TinyMCE has a variety of configuration options to assist with content filtering/validation (https://www.tiny.cloud/docs/configure/content-filtering/) to only allow those types of tags you want created, etc including:
https://www.tiny.cloud/docs/configure/content-filtering/#valid_elements
https://www.tiny.cloud/docs/configure/content-filtering/#extended_valid_elements
https://www.tiny.cloud/docs/configure/content-filtering/#valid_children
https://www.tiny.cloud/docs/configure/content-filtering/#schema
https://www.tiny.cloud/docs/configure/content-filtering/#invalid_elements
However, regardless of the front end design, you should always re-check submitted content on the server to ensure it is safe. There is simply no way around that need. What constitutes "safe" is likely a business decision based on what your application does and who uses it.
There are many different libraries you can use server side to do this sort of validation/cleansing so depending on your specific server side setup you can find libraries that allow you to "sanitize/purify" the submitted HTML.
I would note that TinyMCE (by default) should not allow <script> tags in your content so it is likely that such behavior could be due to your current configuration.
The setup: I have a Blogger blog set up on a domain name as blog.mydomain.com. The main site site at mydomain.com is running Umbraco CMS.
The problem: I need to have the navigation from the CMS transported to Blogger somehow, so that making a change on the main website doesn't require the extra step of modifying the navigation inside Blogger.
Generating the navigation data on the CMS side in what ever format it needs to be (XML, unordered list, JSON, etc) is not a problem. The problem is getting the data from Umbraco to Blogger after it is generated.
I'm not yet willing to use Javascript, as this would seriously impair the website for users browsing without Javascript. (Too bad because AJAX would be a very workable solution.)
I've tossed around the idea of using an iFrame. How would this work for a navigation system including sub-menus? Creating and deleting multiple iframes is out of the picture, since I don't want to use Javascript. I could use one large iframe to allow for the sub-menus, but then it would cover content at the top of the content area, rendering it unclickable.
I'm thinking about how you could do this, but while I do - in this day-and-age javascript has become very common. Most users are going to have it, and those with it disabled really shouldn't be on the web. Is this the only reason you don't want to use javascript? Around 2% according to YDN have js disabled, and that's lower from other countries. As time goes on that 2% should get lower, I don't see that as an issue. However if you absolutely can't use javascript, I'll keep thinking. I might have an idea, I'll need to test it though.
It's not possible to use IFrame, cause of same origin policy. Both sites are on different domains, when user click menu item inside IFrame, there is no way to call parent window.
There are few ways how this can be done.
1) Javascript solution. Use json rpc, or another cross-domain calls. Load menu from your CMS and render it. Yes, this requires javsascript, but, seriously, show me the site, which does not use javascript.
2) Direct server communication.
Is it possible to perform http call from blogger ? If so, just perform http call to your CMS from Blogger, get data and render it.
3) Mixed flash/javascript solution. Flash can perform http call regardless of same origin policy. Get data with flash, use ExternalInterface to call Javascript function to render data.
There is no another way to do it. I suggest you to use javascript solution
You could build an HTML skeleton of empty ULs in Blogger (the max that you might need) to hold your navigation contents, and then link to an Umbraco-generated external stylesheet.
This stylesheet could fill those LIs with CSS generated content using the :before and :after pseudo-elements, and hiding unused LIs with CSS display: none.
An example of this is at: http://jsfiddle.net/5bXja/1/
This works in IE8+ so depending on your clients, this may-or-may-not be more widely supported than Javascript. Likely not. ;-)
Hi I am building a small web based email client. I am facing problems in displaying HTML mails. What are the best practices involved in displaying an HTML mail? Some things I found
Css Reset
Strip body tag in the mail
First of all, it's important to not allow all the CSS and HTML tags. I would look for the file and allow a defined set of HTML tags and CSS attributes.
For example, if you reset the CSS, you can still send stuff like <iframe>, <form> and all other possible malicious tags.
So I would start of thinking what kind of HTML tags would you like to support, and strip all other ones out of it. And then the same for the CSS.
This is by no means easy. I mean you also would have to take in account things like people trying to break your interpreter...
You could look into this Sitepoint Blogpost, it describes how people should code HTML-emails. So it might be a good idea to start there and see what's usually supported.
The one sentence answer would be "1. Use table-based layouts, 2. only inline CSS, and 3. test in every email client possible."
The client testing is probably the most important because every email client (and client + browser combination) may have its own quirks and many are just learned along the way; such as using HTML attributes width & height because Outlook won't always follow the inline styles for width & height, or that Gmail tends to add margins around images unless you explicitly set margin:0 for the HTML elements, etc. etc.
When fixing the look of an HTML email in one client ends up breaking it in another client, don't keep adding more and more styling: try to simplify the HTML/CSS, even if it means writing more markup. For example, if padding and margins don't look right, the same look could be achieved by adding more rows or columns to the table and fixing their heights/widths. More tags is simpler than worrying about how all the email clients will render the CSS box model.
There's a lot of articles and blog posts on HTML-for-email such as http://articles.sitepoint.com/article/code-html-email-newsletters that are helpful -- though a lot are out of date with newer versions of clients.
I am thinking of converting my forum input textarea exclusively to TinyMCE HTML editor. I already have both options but it is a pain maintaining both and inserting images in textarea needs preview etc...
This is more of a general question. Do you think it is safe to include HTML editor (with all the safety measures like paste only text, filter for html not allowed etc...) as the only kind of editor on a forum? It's 2011 and machines are generally fast, connection are better.
What are the downsides of using HTMl editor instead of text field? I can not imagine a blog CMS to have "normal" textarea for input.
But for some reason on forums I do not see many html editors... Even the TinyMCE site has a textarea for their editor. So is there really something to watch out for and a no go...?
I know it is more of a phylosophical question, but I guess you have experience with forums, blogs, etc...
My site is about cooking and beeing able to insert pictures (and upload them) the easy way seems to be a big plus for our home cooks ;-)
If you don't consider security (you'll need to filter the HTML input on the server side so it won't contain anything dangerous), there's only the user experience left for consideration. On a forum you write text most of the time. There's seldom any use for more functionality than bold, italics and images. The solution used here on Stack Overflow addresses this by having a very limited set of functions, and applying it in the textarea with a sane markup language.
Other forums either use old software or didn't think the improved user experience was worth the effort. The textarea-only solution fits most forums well enough since most of the input is text-only anyway.
I do think you would benefit from HTML input. Make sure that only allowed HTML can be sent though, since the user can circumvent everything on the client side.
TinyMCE uses Javascript to add functionality to an existing textarea. If Javascript is disabled, then the user will be presented with a normal textarea anyway.
I would say it's relatively safe, as long as all input from the user is validated on the server before it's used for anything.
I have made a simple blog using Node/Express/Mongo/Jade (and/or HAML.js). I used (and slightly updated) the blog app from this tutorial, which itself an update of one from howtonode.org
I can render attributes such as links, etc., with the template engine just fine, but when I pass data from the db, none of the html renders. I get plain text print-outs of the HTML. I figure I need some other node packages/modules to render the 'dynamic' content, but I don't know where to start.
In jade, when you're passing content you DON'T want to be escaped, be sure you pass it along as != instead of =
BE EXTREMELY CAREFUL THOUGH! If you don't manually parse out the bad stuff, you could make your website extremely vulnerable.
You can read some more jade documentation here