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

Paul Cartmell paul at starcode.co.uk
Wed Mar 23 14:22:17 UTC 2016


Hi Jim


The pen-test definitely did not demonstrate the ability to execute XSS and it is indeed JavaScript.

I agree that it is a weakness at best, or even at all given the infrastructure we have in place.

Most of the input is free text and therefore is hard to guard against and we haven't done any further validation other than the escaping.


I do agree that other consuming systems which use the data may be vulnerable however should that be this application's concern?


Thanks for the input so far.


Regards

Paul.

________________________________________
From: Jim Manico <jim.manico at owasp.org>
Sent: 22 March 2016 22:30
To: Paul Cartmell; security101 at lists.owasp.org
Subject: Re: [OWASP-Security101] Security Question - Cross Site Scripting [Stored]

 > The actual data is stored 'as-is' (i.e. unescaped characters) and it
is this that has been identified as 'Stored XSS'.

Has the pentest demonstrated the ability to execute XSS? (Javascript?)
Looks like "no".

So the pentester found that a real XSS attack could be stored in the
database, but they could not execute it? That might be a "weakness" at
best (and it is worth mentioning), but it's not a Stored XSS.

Also,I dare say that a webservice does "not have xss" per say, but the
UI that consumes that attack and does not escape or defend properly is
vulnerable.

Now, let's go back to the point that this is a weakness to consider.

Is there a way to enhance your input validation so less of these attacks
are allowed to be stored in your database? What kind of validation are
you doing?

Note: For some kinds of input (like open text fields for conversation) ,
validating them strictly to prevent XSS is almost impossible which is
why escaping in the UI is the most critical defense.

Regards,
Jim



On 3/22/16 11:29 AM, 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



More information about the Security101 mailing list