[sword-devel] RTFHTML filter not escaping HTML entities

DM Smith dmsmith at crosswire.org
Sun Dec 30 14:20:40 MST 2018 

What is the likelihood/risk of an untrustworthy conf?

— DM Smith
From my phone. Brief. Weird autocorrections. 

On Dec 30, 2018, at 4:14 PM, Jaak Ristioja <jaak at ristioja.ee> wrote:

>> It looks like BibleTime, too, is guilty of not properly escaping those.
> 
> Actually it seems that the RTFHTML filter in Sword (and Sword++ for that
> matter) does not properly escape HTML entities included in the RTF. So
> if the RTF includes <b> or any other HTML tags, these are passed on
> unmodified, wherease they should instead be escaped using &lt;, &gt; and
> similar entities. This could allow arbitrary HTML injection from the RTF.
> 
> J
> 
> 
> 
>> On 30.12.18 23:03, Jaak Ristioja wrote:
>> Btw, grepping my ~/.sword/mods.d/*.conf shows that <a> tags are used
>> elsewhere as well, e.g. in About= and DistributionNotes=. There are even
>> some <b>, <i> and <u> tags in About= and History_x.x= entries.
>> 
>> It looks like BibleTime, too, is guilty of not properly escaping those.
>> 
>> J
>> 
>>> On 30.12.18 10:32, David Haslam wrote:
>>> Wouldn’t the points about HTML apply just as equally to the existing ShortPromo key ?
>>> 
>>> Some front-ends already jump to the URL specified in the href, and can open a browser to do so.
>>> 
>>> David
>>> 
>>> Sent from ProtonMail Mobile
>>> 
>>>> On Sun, Dec 30, 2018 at 00:39, Jaak Ristioja <jaak at ristioja.ee> wrote:
>>>> 
>>>> I like the idea, because it is useful information for the users. Here
>>>> are some of the thoughts I gathered for this:
>>>> 
>>>> <brainstorm xmlns="https://en.wikipedia.org/wiki/Brainstorming">
>>>> 
>>>> Why can't the About= entry contain this information?
>>>> 
>>>> I'm unsure whether "UnlockInfo" is the best name.
>>>> 
>>>> Is it safe to assume that this entry will only be relevant for modules
>>>> with a CipherKey= entry?
>>>> 
>>>> Using HTML might be a can of worms:
>>>> * What version of HTML is permitted?
>>>> * How do we ensure future-compatibility?
>>>> * If the contents for the UnlockInfo field are to contain a segment of
>>>> HTML (and not a whole HTML document), what is the content model?
>>>> * For example, would it be safe to embed the contents of the
>>>> UnlockInfo field directly inside a <td> element or should it be a <p>?
>>>> * Can UnlockInfo= contain
>>>> <img>/<audio>/<video>/<object>/<embed>/<script> etc elements?
>>>> * How about attributes, e.g. <strong
>>>> style='background:url("http://track.me/I_consent")'> or <span
>>>> onClick="doBadStuff()">?
>>>> 
>>>> Modules can originate from untrusted sources. I think it might be a bit
>>>> too much to assume that all frontends can properly sanitize the HTML
>>>> value, unless we only allow a very restricted subset of the HTML syntax,
>>>> e.g. only plain text, HTML entities and <a> elements only one allowed
>>>> and mandatory href attribute. Note that <b> and <i> etc are discouraged
>>>> in HTML5, <u> was completely redefined. Will <a> ("anchor") still be
>>>> valid in HTML6 or will <link> be repurposed for hyperlinks as well?
>>>> 
>>>> Hence I suggest to use a simple URL (or URI, RFC 3986) instead of HTML.
>>>> Simple documents (including HTML pages, PDF or any other types of files)
>>>> could be embedded using the data: URI scheme (RFC 2397). Frontends could
>>>> pass the URI to the OS/desktop/browser to be opened or attempt to
>>>> display the information inline (e.g. show a web view widget for
>>>> HTTP/HTTPS URIs or similar). Optionally, frontends can display a
>>>> warning/confirmation dialog to the user before opening the URI.
>>>> 
>>>> Perhaps it would be wiser to have two fields: one for the URI and
>>>> another for plain text? I currently have no suggestions for the exact
>>>> semantics of naming of such entries, but both of these could be
>>>> displayed by frontends. The plain text could be a description of the
>>>> URI, or contain full information about obtaining the key. One or both of
>>>> the entries could be optional. Frontends could opt to detect URLs in the
>>>> plain text as well and render these as hyperlinks.
>>>> 
>>>> Or perhaps we should use a subset of markdown or similar instead?
>>>> However, other markup languages could suffer from problems similar to HTML.
>>>> 
>>>> </brainstorm>
>>>> 
>>>> J
>>>> 
>>>>> On 30.12.18 00:02, Troy A. Griffitts wrote:
>>>>> Dear Frontend Developers,
>>>>> 
>>>>> In an effort to gain more publishers-- even those who desire to lock and
>>>>> sell some of their modules, I would like to add a new .conf entry:
>>>>> 
>>>>> UnlockInfo
>>>>> 
>>>>> Up until now, we've relied on the About entry containing something that
>>>>> lets the user know how to obtain unlock codes from publishers selling
>>>>> codes to unlock their modules.  This entry would isolate just those
>>>>> instructions to a specific entry and would allow a frontend to do
>>>>> something like:
>>>>> 
>>>>> If (moduleToInstall.getConfEntry("UnlockInfo")) {
>>>>> 
>>>>>  showDialog("<p>The publisher of this modules requires for you to
>>>>> obtain an unlock code.  This code can be entered below, instructions
>>>>> from the publisher are as follows:</p>" +
>>>>> moduleToInstall.getConfEntry("UnlockInfo"));
>>>>> 
>>>>> }
>>>>> 
>>>>> Like many of our entries, this new UnlockInfo entry will allow HTML
>>>>> links and will likely contain a direct link from the publisher to their
>>>>> store entry to purchase an unlock code.
>>>>> 
>>>>> An example would be something like:
>>>>> 
>>>>> UnlockInfo=An unlock code for the Larry Fitzgerald NFL HOF Edition of
>>>>> the New Testament, with memorable career moments encouraging the
>>>>> believer to press on when those around fall short, may be obtained
>>>>> directly from the NFL store here: <a target="_blank"
>>>>> href="https://nfl.com/shop/lf-nfl-hof-nt-sword-module">Larry Fitzgerald
>>>>> NFL HOF Edition of the New Testament - SWORD Module</a>
>>>>> 
>>>>> Let me know if you have any comments or ideas,
>>>>> 
>>>>> Troy
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>>> Instructions to unsubscribe/change your settings at above page
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above page
>>>> 
>>>> _______________________________________________
>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above page
>> 
>> 
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>> 
> 
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

More information about the sword-devel mailing list