Apologies, looks like the second half of the email I just sent got formatted weirdly (I was copying from a failed earlier email attempt that got rejected for attaching images). Just to make sure it doesn’t get buried:
Of course this specific case can be patched on the frontend, but doing some kind of HTML sanitization escaping into 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 Mon, Jun 8, 2020 at 9:13 PM Melinda Crane <[email protected]> wrote: > 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 <[email protected]> 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" <[email protected]> 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 >> >> >>
