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
>>>
>>>
>>>
>
>
