Thanks, Melinda, for the detailed explanation. I am able to reproduce the issue. wIll provide the patch for this.
On Tue, Jun 9, 2020 at 9:34 AM Madhan Neethiraj <[email protected]> wrote: > 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 > >> > >> > >> > > >
