@RBGE Agree. Simply converting < into &lt; & > into &gt; takes care of security and content. Since OSTicket uses a ready library HTMLawed, its a default implementation I guess by the library.

A small issue. My solution above only works for HTML emails.
@ntozier Can you suggest what should be tweaked for TEXT emails?
Thanks a ton in advance!!

I scanned the entire class.format.php file but could not locate any function or code which works for text emails. Any pointers are appreciated.
Thanks

    Thanks @ramrajone
    In the latest version of OSTicket, this code is on line 238.

    redactor.insert.html(canned.response, false);

    I modified the code as you recommended but it did not help. In my case though, the issue is not with canned responses but with incoming text/plain emails. This issue if really hitting me hard.
    It would be really great if someone can suggest a code edit.

    Just to recap, commenting the following line helped in fixing this issue with text/html emails.

    includes / class.format.php
#$text = Format::safe_html($text, array('spec' => $spec));

    But I'm unable to find the code which needs to be modified for text/plain emails.

    Thanks in advance!

      Thanks @ramrajone but I did not really follow what you are trying to convey 🙁
      I checked both the links you shared and I agree, HTMLawed is improving security. In my case, since its a specific use case, I need to show content between <>.

      My mail server is hosted on Cpanel, I'm trying to see if I can make any changes to the incoming email on-the-fly and convert it from text/plain to text/html. Fortunately, I'm able to bypass the filters for html emails.

      Thanks again

      On another note, what changes can I make to completely bypass HTMLawed for all types of emails - text & html?

        Already done that. My code looks like this:
        ` function sanitize($text, $striptags=false, $spec=false) {

            //balance and neutralize unsafe tags.
    //$text = Format::safe_html($text, array('spec' => $spec));
    //above line commented on 2020-02-05 to avoid stripping of <111111>
    $text = self::localizeInlineImages($text);

    //If requested - strip tags with decoding disabled.
    return $striptags?Format::striptags($text, false):$text;
}`

        This is working fine but only for text/html emails.

        If I get an email with content-type = text/plain, then the <xxx> is still stripping.

          Thanks @KevinTheJedi -- it worked.

          File: include/class.thread.php

          inside the class:
          class TextThreadEntryBody extends ThreadEntryBody {
          I commented the following code:

          function getClean() {
        return Format::htmlchars(Format::html_balance(Format::stripEmptyLines(parent::getClean())));
    }

          Hope it helps others looking for a similar solution.

          Happy weekend!!

          @rsclmumbai

          I hope no one else implements this as it’s a security risk. This does not open you to XSS attacks only, people can use XSS to start different, more serious attacks or possibly execute a different attack altogether. Just all around not a good idea. I understand your use case and such but really not a good idea from security standpoint.

          At some point in the future we hope to implement code blocks or something similar to say “Don’t sanitize/balance content inside this block of code”. This will alleviate most of these types of issues. This is not set in stone, just on our feature request list.

          Cheers.

          Thanks @KevinTheJedi
          I totally agree with you. I'm able to take this risk since we are using OSTicket strictly internally.
          Nevertheless, I hope to see the Don't Sanitize..... feature in the future releases.
          Thanks for the awesome helpdesk system & superb support!!

            2 years later
            2 years later

            Is there anything we can do now on this? We use our osTicket for a tech support help desk so often emails contain snippets of HTML or XML which all get stripped out.

            Surely encoding < as &lt; and > as &gt; would resolve this problem? then it would be displayed rather than rendered?

            I appreciate this is coming in v2, but (correct me if I'm wrong?) we don't know when that's coming.

              asmith3006

              You can modify the codebase but you’ll likely open yourself up to XSS and similar attacks. Proceed at your own risk.

              Cheers.

                Write a Reply...