[OWASP-Security101] Security Question - Cross Site Scripting [Stored]
paul at starcode.co.uk
Thu Mar 24 09:56:11 UTC 2016
On the web service point, obviously the data would have to be escaped before transport due to it's nature however would you say that the content should be double escaped?
Or should there be mechanisms for providing single and double escaped formats from the same service?
From: Jim Manico <jim.manico at owasp.org>
Sent: 23 March 2016 18:56
To: Paul Cartmell; Tasha CARL; security101 at lists.owasp.org
Subject: Re: [OWASP-Security101] Security Question - Cross Site Scripting [Stored]
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
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 -
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?
> 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
> 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
> 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
> 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,
> (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
>> 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...
>> 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
>> > How should the data be stored within a database - escaped or unescaped?
>> css, etc) so I recommend you focus your efforts on escaping in the user
>> 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
>> Sure you can escape in the database, but you will have to un-escape and
>> re-escape in the right content.
>> 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...
>>> 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
>>> List Run By OWASP
>>> List Admin: Michael.Coates at owasp.org
>> Security101 mailing list
>> Security101 at lists.owasp.org
>> List Run By OWASP
>> List Admin: Michael.Coates at owasp.org
More information about the Security101