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

Paul Cartmell paul at starcode.co.uk
Wed Mar 23 14:49:44 UTC 2016


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