Hi Melinda, Thanks for the details on the XSS issue; it helped to investigate and verify the fix. This fix is now merged in master and branch-2.0 branches.
About the concerns with eval in requires.js: Atlas UI uses handlebar templates to render HTML; requires.js gets the handlebar templates as a string and uses eval function to generate HTML for dynamic rendering. I added necessary escapes to avoid XSS issues for handlebar templates. Thanks On Thu, Jun 11, 2020 at 2:03 PM Bolke de Bruin <bdbr...@gmail.com> wrote: > I'm working on a POC that shows the need for server side escaping due to > second order XSS (stored XSS). > > That's taking a bit of time. > > B. > > Sent from my iPhone > > > On 11 Jun 2020, at 02:30, Madhan Neethiraj <mad...@apache.org> wrote: > > > > Melinda, > > > > As I said earlier, I don't agree on server side escaping HTML characters > in its input and output. Escaping must be handled by components that are > prone to issues in dealing with unescaped data. We are discussing potential > XSS in UI while dealing with data from user/server, which requires UI > updates to perform necessary escapes. As I said earlier, Keval is already > looking into this. > > > > And, I haven't heard yet (from you/Bolke/anyone else) on any server side > issues that require Atlas server to escape HTML characters in data it > receives/responds. I strongly suggest to not treat this as a release > blocker. If anyone thinks it is, please come out with clear use > cases/examples quickly. > > > > Regards, > > Madhan > > > > > > > > On 6/10/20, 3:22 PM, "Melinda Crane" <mcr...@snap.com.INVALID> wrote: > > > > Dear Madhan and Bolke, > > > > > > Are there any updates on this topic? The discussion so far has been > pretty > > exciting to see and hear - having the sanitization feature as an > optional > > config like Bolke mentioned would be real useful to us (since we know > our > > data should never contain html characters), and it seems like it > would be > > useful for other companies down the road who have stricter security > > requirements. Where the sanitization would happen is of course > completely > > up to you folks! > > > > > > Cheers, > > > > Melinda Crane > > > >> On Tue, Jun 9, 2020 at 10:46 AM Madhan Neethiraj <mad...@apache.org> > wrote: > >> > >> Bolke, > >> > >>> 1. Filtering input on arrival where the user cannot manipulate it > >> anymore (i.e. server) > >> It's not clear what you expect the server to do here? Should HTML > >> characters be escaped in all inputs, before saving the data in its > store? > >> Can you give few examples of server-side manipulation due to unescaped > HTML > >> characters? > >> > >>> 2. Encode data on output > >> I think asking the server side to escape all HTML characters in its > >> response is a very bad idea. Consider forcing such a requirement on a > RDBMS > >> - wouldn't this mandate every client to un-escape every column value > >> returned for queries? Can you add references to applications that > perform > >> HTML escape of all its REST API responses?. > >> > >>> 3. Set correct Http content headers (e.g. application/json) > >> This is already being done. Do you find this missing for any specific > >> usecases? > >> > >>> 4. Set correct Content Security Policy. > >> This is being looked into. > >> > >> Regards, > >> Madhan > >> > >> > >> On 6/9/20, 12:49 AM, "Bolke de Bruin" <bdbr...@gmail.com> wrote: > >> > >> Hi Madhan, > >> > >> I don’t think solving this on the front-end is sufficient and the > >> defense should be more in-depth. The front-end is after all client side > and > >> can be manipulated by the user. Typically one solves XSS > vulnerabilities by: > >> > >> 1. Filtering input on arrival where the user cannot manipulate it > >> anymore (i.e. server) > >> 2. Encode data on output > >> 3. Set correct Http content headers (e.g. application/json) > >> 4. Set correct Content Security Policy. > >> > >> Your proposed solution does not fit any of those criteria. If you are > >> worried about compatibility I suggest making it a server side > configuration > >> variable (e.g. atlas.server.insecure_escaping) which should default to > >> “false” imho and alternative could be to enable configurable escaping > but > >> that’s more complex. > >> > >> Note that in this case also #4 CSP headers seem to be very loose > >> (unsafe-inline, unsafe-eval) which add to the attack surface: > >> > >> > >> > https://github.com/apache/atlas/blob/master/webapp/src/main/java/org/apache/atlas/web/filters/HeadersUtil.java#L44 > >> > >> Regards, > >> Bolke > >> > >> Verstuurd vanaf mijn iPad > >> > >>> Op 9 jun. 2020 om 06:04 heeft Madhan Neethiraj <mad...@apache.org> > >> het volgende geschreven: > >>> > >>> 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" <mcr...@snap.com.INVALID> > >> 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 <mcr...@snap.com> > >> 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 <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 > >>>>> > >>>>> > >>>>> > >>> > >>> > >> > >> > >> > > > > >
