Guillemets lead to imcomplete text parts

Comments

• ntozier

  December 2017

  Please help us to help you by reading and following the posting guidelines located in this thread: Please read before requesting assistance.  The more information you give us the better we will be able to assist you. Thank you.

  
  

  guillemets (aka < >) are HTML reserved characters.  The third party text editor (It's called Redactor) sounds like it isn't handling them properly.  You can try using the source view and entering them that way, or shutting of HTML.
  
  I'll ping the devs to take a look at this but I dont think that this is an osTicket issue per se, and is a Redactor issue.
• KevinTheJedi

  December 2017 edited December 2017

  @dc_ao

  
  

  I believe @ntozier is correct in that this is more of a Redactor issue. You can look into how Redactor cleans the tags and such via js/redactor.min.js, js/redactor-plugins.js, and js/redactor-osticket.js. You can add allowed tags to Redactor so that it will leave them alone when parsing. After adding the tag to the allowed tags, see if they are working how you wan them to. If they are working correctly but still stripping everything after then you need to look into how we parse the response body via include/class.format.php -> function sanitize(). 

  
  

  Please Note:

  This task is VERY dangerous as you might be opening yourself/company/users to XSS...which is pretty serious and no fun at all lol

  
  

  I hope this helps! Cheers.
• dc_ao

  December 2017

  Hi ntozier,

  I checked the source view before I opened this ticket. Like expected, HTML specialchars are treated properly.

  Inspecting the sent POST request I see properly encoded HTML aswell:

  
  

  But the database entry contains only:

   <br /><br />Sos so so so<br /><br /><br /><br /> 
  

  This looks very much as if the sanitizer of osTicket did the deed, not Redactor.

  
  

  I'll hava a look into the function KevinTheJedi mentioned, maybe I can contribute a solution.

  
  

  Cheers,

  Andreas
• dc_ao

  December 2017

  Ok, looks like the reason is in the safe_html function resp. in its default options:

  
  

          $options = array_merge(array(

                      // Balance html tags

                      'balance' => 1,

                      // Decoding special html char like &lt; and &gt; which

                      // can be used to skip cleaning

                      'decode' => true

                      ),

                  $options);

  Setting 'decode' to false seems to solve the issue without any negative side effects (so far ;-))
• Micke1101

  December 2017

  @dc_ao When i was looking into this editing content did not work with just changing decode to false, see this thread: http://osticket.com/forum/discussion/90583/bug-sanitzing-with-hmlawed-redactor-and-js-code-tag-in-frontend-is-ignored-and-will-be-rendered
• dc_ao

  December 2017

  @Micke1101 I just fiddled around a bit width <code> sections and HTML characters in general and every interface (GUI and mail) behaves as expected now, including edits.

  
  

  BTW I run osTicked 1.10.1 
• ntozier

  December 2017

  Can you post what you did to get it working?
• KevinTheJedi

  December 2017

  @dc_ao I would do EXTENSIVE testing on your system if I were you...since you allowed '<' tags and HTML tags, you could've easily opened yourself to XSS.
• dc_ao

  December 2017

  @ntozier include/class.format.php line 295, changed 'decode' => true to 'decode' => false in the default config.

  
  

  @KevinTheJedi all I did was to disable the decoding of already encoded htmlspecialchars before sanitizing the content..

  Though I cannot imagine a certain vulnerability by this, I tried all kinds of scenarios to insert scripts and tags, and none of my attempts lead to an unexpected (resp. unsecure) result.

  If you could outline a scenario you have in mind, I will thankfully test it aswell.