Melinda,
Thank you for reaching out to Apache Atlas community.
As you noted, AtlasJsonProvider is used to deserialize/serialize REST API
requests and responses. In addition, methods in AtlasJson are used in to
convert to/from Json. It will help if you can add few examples of potential
issues with the current implementation.
Keval is looking into the frontend for potential issues and should get back
early next week.
Thanks,
Madhan
On 5/29/20, 6:50 PM, "Melinda Crane" <mcr...@snap.com.INVALID> wrote:
Dear Apache Atlas devs,
I’m from Snapchat, we’re working on building a catalog on top of Apache
Atlas. I noticed looking at the frontend for Atlas that there seem to be
several places vulnerable to XSS, so I’ve got some questions for the
community (especially frontend folks) or other partner companies who may
have dealt with similar problems:
1.
the CSP allows unsafe-inline and unsafe-eval
2.
the backend JSON content provider, AtlasJsonProvider, doesn’t appear to
do any forced escaping.
Regarding the unsafe-inline and unsafe-eval, I saw some inline scripting
going on with the index html file in dashboardv2/v3, but that doesn’t look
bad to move out. However, I noticed a lot of the third party node modules
use inline scripting (such as backgrid-filter and
bootstrap-daterangepicker) and/or eval() (such as javascript-stringify and
even requirejs). I’d like to get rid of unsafe-inline and unsafe-eval in my
CSP; are there any recommendations on how to deal with the third party
plugins to achieve this?
For the forced escaping, are there any other major places on backend
besides the JSON provider that should definitely be escaped? Also, since
the AtlasJsonProvider seems to be *the* default object mapper, are there
any insidious or otherwise consequences of force escaping HTML sensitive
characters in it?
Thank you kindly for any advice.
From, Melinda Crane
