[OWASP-Security101] Security Question - Cross Site Scripting [Stored]

Jim Manico jim.manico at owasp.org
Wed Mar 23 18:56:34 UTC 2016


I sent those comments in private, but in short - I think this is an 
acceptable philosophy, but not one I agree with. I focus my XSS efforts 
in UI security. Not "input" security, which is frail for this kind of 
workflow.

I do agree that webservices - while they cannot "secure" open text 
reliably - they can provide API's to retrieve data already escaped. 
That's the webservice responsibility, not to "sanitize" and "stop" 
attacks of this nature (impossible without doing functionality harm) - 
but to provide ways to other developers to retrieve dangerous data - 
escaped.

On 3/23/16 4:49 AM, Paul Cartmell wrote:
> Hi Tasha
>
>
> Thanks for the info, appreciate your opinion.
>
> I do understand your concerns and guarding against elements you mention does make sense.
>
> However, I'm always a little wary of coding for 'what-if' when a solid development process is in place.
>
>
> Jim - do you have any comments on the view below?
>
>
> Thanks
>
> Paul.
>
> ________________________________________
> From: Tasha CARL <tasha at carl.pro>
> Sent: 23 March 2016 07:57
> To: Paul Cartmell; Jim Manico
> Subject: Fwd: Re: [OWASP-Security101] Security Question - Cross Site Scripting [Stored]
>
> Hello Paul,Hello Jim,
>
> I would like to add my point of view to the discussion.
>
> Personally, I would classify your case as Stored XSS as well and what
> your pen tester told you is in my opinion correct.
>
> The problem with non-sanitised data in the database is that it may very
> well not be a problem NOW, but it will be very likely become one later.
>
> Already the NOW is difficult to assess, since can you be sure that all
> possible output cases are handled cleanly? Are you sure that there is
> not a little administration screen in one corner of the application that
> in one way of the other will display the data unfiltered? Or an error
> screen maybe? Or just a bug because a developer didn't got his coffee in
> time?
>
> Thinking of future times, nobody knows how an application evolves. An
> inexperienced developer may just decide in one year from now to output
> the data in a new screen he has been tasked to develop, a manager
> decides the change of a functionality and your client side validation
> becomes leaky. You need 100% unit tests coverage to only have a chance
> to prevent regression. (Repeated pen testing will not help in this
> case.)
>
> Or maybe you plan a web-service to your (new) clients and they do not
> sanitise the data on their side before returning it to a GUI, despite of
> the fact that you have stated clearly in your interface specifications
> that it must be done. :-)
>
> It's a bit the same as with "uploaded documents". Would you store
> uploaded documents and files in your database before performing a
> malware scan and trust that all download paths perform a malware scan on
> their side? I guess, you would rather prefer to scan at upload and not
> insert the toxic stuff in your base at all. :)
>
> Please do not understand this message as a cheap lesson. It is not meant
> to be one. Rare are the project managers and stakeholders that actually
> ask if they have doubts or that actually verify and try to understand
> such reports. Hats off to you!
>
> Personally, I would recommend to trust your pen tester on this
> diagnosis.
>
> I understand that such reports are not nice to receive, but nobody
> (developer) is perfect and security is not easy to keep in mind during
> coding marathons. That's why pen testing is actually a separate full
> time job, as is software developer and project manager.
>
> Best regards,
> Tasha
>
> (I've trouble posting to the list,sorry)
>
> On Tue, Mar 22, 2016, at 10:29 PM, Paul Cartmell wrote:
>> Aloha Jim
>>
>>
>> Many thanks for the reply.
>>
>>
>> To give a little more context to the issue, I have an application which
>> has been pen-tested and a vulnerability of Stored XSS highlighted.
>>
>> I believe this to be a mis-diagnosis as we do escape EVERYTHING at the
>> client boundary prior to UI display.
>>
>> The actual data is stored 'as-is' (i.e. unescaped characters) and it is
>> this that has been identified as 'Stored XSS'.
>>
>> It is *purely* the storage that has been highlighted as the
>> vulnerability, as the UI escaping has been fully tested and passed with
>> no issues.
>>
>> All possible data 'exit routes' (including a web service) are properly
>> escaped therefore I believe the application does not have a Stored XSS
>> problem.
>>
>>
>> I'm no security expert however I do think that my application is safe
>> from this issue given the above measures that have been put in place;
>> would you agree?
>>
>>
>>
>> Thanks again...
>>
>>
>> Paul.
>> ________________________________________
>> From: Jim Manico <jim.manico at owasp.org>
>> Sent: 22 March 2016 20:49
>> To: Paul Cartmell; security101 at lists.owasp.org
>> Subject: Re: [OWASP-Security101] Security Question - Cross Site Scripting
>> [Stored]
>>
>>   > How should the data be stored within a database - escaped or unescaped?
>>
>> Well you need to escape in one of several contexts (javascript, html,
>> css, etc) so I recommend you focus your efforts on escaping in the user
>> interface.
>>
>> The best way to stop injection (and XSS is just injection) is to provide
>> your defense as close to the boundary between the parser that can hurt
>> you and untrusted data. For XSS, that means escaping EVERYTHING in your
>> UI.
>>
>> Sure you can escape in the database, but you will have to un-escape and
>> re-escape in the right content.
>>
>> Aloha,
>> Jim
>>
>>
>> On 3/22/16 5:48 AM, Paul Cartmell wrote:
>>> Hi there
>>>
>>>
>>>
>>> I'm looking for some clarification on a particular issue relating to Stored Cross Site Scripting.
>>>
>>>
>>> To protect against this vulnerability I understand that untrusted content should be escaped to prevent execution within the client.
>>>
>>>
>>> How should the data be stored within a database - escaped or unescaped?
>>>
>>>
>>> It is my understanding that the data can be stored unescaped and as long as the content is escaped prior to client presentation, this is acceptable.
>>>
>>>
>>> Whilst the data is potentially unsafe if stored unescaped, if all possible routes to the client are correctly handled, is the vulnerability mitigated?
>>>
>>>
>>> Any input gratefully received...
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>> Paul.
>>>
>>> Paul Cartmell
>>> StarCode Software
>>> m: 07843 017397
>>> e: paul at starcode.co.uk<mailto:paul at starcode.co.uk>
>>> w: www.starcode.co.uk<http://www.starcode.co.uk/>
>>> _______________________________________________
>>> Security101 mailing list
>>> Security101 at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/security101
>>> List Run By OWASP
>>> List Admin: Michael.Coates at owasp.org
>> _______________________________________________
>> Security101 mailing list
>> Security101 at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/security101
>> List Run By OWASP
>> List Admin: Michael.Coates at owasp.org



More information about the Security101 mailing list