dspace-angular icon indicating copy to clipboard operation
dspace-angular copied to clipboard

HTML tags in administrative workflow view are being evaluated

Open firoball opened this issue 3 years ago • 7 comments

Describe the bug First of all, I am not sure whether this is really a bug or more like a feature. Since I came across this while doing some XSS attempts on a local DSpace 7.1.1 setup, I entered some HTML/JS code in the resource submission form. The sanitizer of Angular appears to detect my attempts and makes them safe. Still, in the administrative workflow the HTML tags are evaluated:

grafik

To Reproduce Steps to reproduce the behavior: Submit new resource, enter <img src="https://upload.wikimedia.org/wikipedia/en/thumb/9/9a/Trollface_non-free.png/220px-Trollface_non-free.png" onerror=alert(document.cookie);> in any of the text fields. Hit deposit and check administrative worklow.

Expected behavior HTML tags are stripped entirely or at least are not being evaluated as in the other views.

firoball avatar Jan 22 '22 16:01 firoball

Thanks @firoball for the ticket.

  • Verified this does NOT occur on Item pages (i.e. /items/[uuid]). On these pages HTML is not evaluated
  • However, it strangely DOES occur on any lists of items (seach/browse/mydspace), in either the dc.title or dc.description.abstract fields. Javascript in HTML doesn't appear to execute...but I can get images to load and also links or formatting to work.

This is unexpected behavior. I'll bring this over onto our board to work on.

tdonohue avatar May 09 '22 16:05 tdonohue

We have some contributors who write quite elaborate abstracts using XMLUI's "Simple HTML Fragment" feature. We'll have to clean up these metadata if text-field markup is unimplemented, or implemented in a different way, and the demand will still exist.

A quick look at lightweight markup languages says to me that they are all much too powerful for metadata markup. If we can eliminate external references (links and images) then this becomes much less problematic. Maybe an examination of print journals will suggest a small set of essential features. From a security standpoint, a small language that only deals with formatting would be best.

OTOH I recall that some sites have requested additional markup such as MathML.

mwoodiupui avatar Jun 07 '22 20:06 mwoodiupui

NOTE for future work. This needs discussion. The initial ticket here implies that these HTML tags should not be evaluated. But, it seems we were evaluating some tags in XMLUI, see https://wiki.lyrasis.org/display/DSDOC7x/Simple+HTML+Fragment+Markup

Therefore, we should discuss whether we can bring that XMLUI feature forward, while also ensuring that XSS (and similar) attacks cannot be achieved (it seems Angular blocks that though, but it may need more testing).

tdonohue avatar Jun 08 '22 16:06 tdonohue

See also #1404

mwoodiupui avatar Jul 25 '22 20:07 mwoodiupui

A lot could be accomplished if we could simply avoid normalizing whitespace in these fields. Then one could have line breaks and paragraph breaks.

mwoodiupui avatar Aug 05 '22 12:08 mwoodiupui

See also #1763 which is loosely related

tdonohue avatar Aug 17 '22 14:08 tdonohue

As explained in #1762, we definitely need line breaks to not be stripped and to be displayed.

We have enabled HTML to the extent provided in XMLUI and have many abstracts that rely on it for proper display. While security is paramount, it would be great if we could continue to offer the option to support HTML to the level currently offered in XMLUI.

I'd rate line break preservation and display absolutely essential and continued HTML support desirable but not essential.

alawvt avatar Aug 17 '22 17:08 alawvt