Dear Madhan, Thank you kindly for your response and for offering to look into potential solutions. I've been trying to step through how the ajax calls are handled, I don't really see the AtlasJsonProvider being used much at all actually for that. My concern is that the data from the ajax calls aren't being sanitized on the backend. I see there is a ton of sanitization happening on the frontend (lots of calls to _.escape()), but they're not all captured. For example.
In CommonViewFunction, in the propertyTable <https://github.sc-corp.net/Snapchat/keystone/blob/master/dashboardv2/public/js/utils/CommonViewFunction.js#L267> function, URLs are not escaped. So I can create an entity that has a key value of https://www.google.com/search?\";><iframe src='\''/'\'' width='\''1'\'' height='\''1'\'' onload='\''window.alert(\"boo\");'\''></iframe> and my script will successfully get successfully injected into my browser when I try to view it. Looks like I can't attach images here but here's the elements: <div class="entity-detail-table"> <table class="table"> <tbody data-id="detailValue" class="hide-empty-value"> <tr class="hide-row"> <td>newSchema</td> <td> <div class="scroll-y"> N/A </div> </td> </tr> <tr class=""> <td>classField</td> <td> <div class="scroll-y"> <a target="_blank" class="blue-link" href="https://www.google.com/search?";> <iframe src="/" width="1" height="1" onload="window.alert("boo");"></iframe> ">https://www.google.com/search ?"> <iframe src="/" width="1" height="1" onload="window.alert("boo");"></iframe> </a></div></td> ... ^You can see the iframe-script combo here. Of course this specific case can be patched on the frontend, but doing some kind of HTML sanitization escaping on the whatever-is-handling-the-ajax (EntityREST or AtlasEntityStoreV2, maybe?) to blanket-catch HTML characters sounds safer. Hope this helps express my concerns. From, Melinda Crane On Sat, Jun 6, 2020 at 2:48 PM Madhan Neethiraj <mad...@apache.org> wrote: > 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 > > >
