Editable html field returns 'Security breach' - how to resolve?

(10 posts) (2 voices)
  1. duane, Member

    Hi.

    I have an editable HTML field which has been working to be updated fine until now. However with the latest update, after submitting the HTML content (even if it contains no HTML), the result returns 'Security breach'. Is there a way to either figure out why or to tell it the content is safe?

  2. myDBR Team, Key Master

    myDBR 6.5.0 tightens the security (for the XSS protection) for normal input fields. Also, make sure you are using the latest myDBR build.

    What is the editable type you are using?

    If you use types html, php, javascript, css or sql, you will get a code editor which allows full code to be included.

    --
    myDBR Team

  3. duane, Member

    The Editable type is richtext which (according to the current documentation) should allow wysiwyg editing of HTML - should this be changed to HTML?

    SELECT 'dbr.editable', 'body_html', 'sp_DBR_posting_update_html', 'inPostHashCode=PostHashEncoded', 'inFieldName="body_html"', type=richtext', "options={'html':1, 'onblur':'', 'richtext':{'width':'100%', 'height':'400', 'menubar': false, 'statusbar': true, 'remove_linebreaks': false, block_formats: 'Paragraph=p;Header 3=h3;Header 4=h4;Header 5=h5;', 'toolbar': true, 'plugins': 'lists advlist code link, autosave', autosave_ask_before_unload: false, 'toolbar': 'undo redo restoredraft | formatselect | bold italic underline | numlist bullist | link | removeformat code' } }";

  4. myDBR Team, Key Master

    Run the updater to get the latest myDBR build. That will fix the 'Security breach' issue.

    Do you plan to edit code that contains possible XSS enabling code (scripts etc) or just plain HTML?

    --
    myDBR Team

  5. duane, Member

    > Run the updater to get the latest myDBR build. That will fix the 'Security breach' issue.
    After updating (to myDBR 6.5.0 build 4758), clearing the cache and reloading - it still returns 'Security breach' (Laptop: chrome 108, macOS 12.6.2; Server: php 7.3, debian 10)

    > Do you plan to edit code that contains possible XSS enabling code (scripts etc) or just plain HTML?
    Just HTML

  6. myDBR Team, Key Master

    Make sure your options is a valid JSON (single quotation marks are allowed). Your autosave_ask_before_unload for example should be 'autosave_ask_before_unload'.

    The type=richtext' is probably already 'type=richtext'?

    myDBR 6.5.0 also includes the latest TinyMCE (6.3.1) for the richtext editing, so you you can check your TinyMCE options.

    --
    myDBR Team

  7. duane, Member

    OK. Once I removed the "'richtext':{...}" options it worked. Now I will explore the latest TinyMCE (6.3.1) options and see how to recreate what I had without triggering a security breach message

  8. myDBR Team, Key Master

    Your richtext options had options that were not enclosed in quotation marks (block_formats and autosave_ask_before_unload. This will cause the "Security breach" error.

    We'll add a check for the valid JSON for editable.

    --
    myDBR Team

  9. duane, Member

    Your findings above are verified (I fixed these issued and gor it working before I saw this). I've also updated for TInyMCE 6 and fixed all the other similar instance of the richtext type field.

    My working code for TinyMCE 6.x is now:

    SELECT 'dbr.editable', 'body_html', 'sp_DBR_posting_update_html', 'inPostHashCode=PostHashEncoded', 'inFieldName="body_html"', 'type=richtext', "options={'html':1, 'onblur':'', 'richtext':{'width':'100%', 'height':'400', 'menubar': false, 'statusbar': true, 'remove_linebreaks': false, 'block_formats': 'Paragraph=p; Header 3=h3; Header 4=h4; Header 5=h5;', 'toolbar': true, 'plugins': 'lists advlist code link, autosave', 'autosave_ask_before_unload': false, 'toolbar': 'paste removeformat code blocks bold italic underline numlist bullist link indent outdent undo redo restoredraft' } }";

  10. myDBR Team, Key Master

    The latest build eases up the option format requirement. Now the option can be in JavaScript object notation, no need for stricter JSON.

    --
    myDBR Team


Reply

You must log in to post.