Melinda, Thank you for adding details. I think the frontend must take steps to prevent JavaScript execution while handling values in REST API responses.
Server side escaping all HTML characters in all responses wouldn’t be the right approach, as browser is not the only consumer of the responses. Consider applications that parse response from Atlas REST APIs; all such applications must be updated to deal with escaped HTML characters in responses. This will likely break existing Atlas integrations. Hope this helps. Regards, Madhan On 6/8/20, 6:31 PM, "Melinda Crane" <[email protected]> wrote: 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 >> >> >>
