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

Scott Brown scott.brown at teamaol.com
Wed Mar 23 15:59:35 UTC 2016


Yes, your data may contain stored XSS. That fact doesn't change just
because you properly handle escaping before presenting it.

If you can limit allowed characters or something so as to whitelist
allowable input to prevent XSS vulnerabilities, that would be prudent.

But is it possible to escape the data properly for all possible output
contexts, without escape conflicts and without mangling the input for some
of those contexts?

See http://lukeplant.me.uk/blog/posts/why-escape-on-input-is-a-bad-idea/
for some discussion along these lines.

All else notwithstanding, in my opinion any consumer of data retrieved from
your storage who, despite knowing it can contain user input, doesn't
properly escape it for their display or output context has committed a
grievous error. And if they don't realize that it can contain user input
because they didn't confirm the possible origins of the data, doubly so.


On Wed, Mar 23, 2016 at 7:49 AM, Paul Cartmell <paul at starcode.co.uk> 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
> _______________________________________________
> 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
>



-- 

*"Forty-two," said Deep Thought, with infinite majesty and calm.*


More information about the Security101 mailing list