RE: SQL Injection

["V. Poddubniy" <vpoddubniy () mail ru>]

Hi,

I think non-browser systems CAN convert (decode) data back to its
original form... So I don't think it's a real problem for you,
especially if you wrote those systems yourself... And it's not reason to
reject security in your application using _only_ whitelists...

--
Best regards,
 Vladimir Poddubniy

> -----Original Message-----
> From: stevenr () mastek com [mailto:stevenr () mastek com] 
> Sent: Wednesday, June 09, 2004 11:25 AM
> To: michaels () phg com au; coley () mitre org; webappsec () securityfocus com
> Subject: RE: SQL Injection
>
>
> Hi Michael
>
> I was just bouncing the idea off the group of encoding 
> blindly. That would convert all HTML tags and so should 
> mitigate the XSS risk to a large extent (even SQL injection, 
> right? ). But would also play havoc with my data, specially 
> since I have non-browser systems reading the data too. 
>
> I feel the white list approach would be the only way to go.... 
>
> Regards,
> Steven Rebello
>
> -----Original Message-----
> From: Michael Silk [mailto:michaels () phg com au]
> Sent: Wednesday, June 09, 2004 10:11 AM
> To: Steven M. Christey; webappsec () securityfocus com
> Subject: RE: SQL Injection
>
>
> Hi,
>
>       There are many many more possibilities for XSS then simply the 
>       <script> tag, of course it depends on where the resulting string
>       ends up, but simply replacing the <script> tag is *not* enough.
>
>       SQL Injection, of course, can not be be mitigated by way of 
>       replacing "<script>" tags either, you aren't really suggesting
>       this are you ?
>
> -- Michael
>
> -----Original Message-----
> From: Steven M. Christey [mailto:coley () mitre org]
> Sent: Wednesday, 9 June 2004 7:52 AM
> To: webappsec () securityfocus com
> Subject: Re: SQL Injection
>
>
>
> > BTW, any opinions on if I just encode all input without 
> checking for any
> > characters? Say converting all <script> to &lt;script&gt; Can anyone
> > still do XSS or SQL Injection in that case?
>
> Not that I can think of, but there might be implications if there's a
> back end.
>
> However...  If the routine is being coded in C or another language
> that's prone to buffer overflows, then you need to make sure to
> account for all the potential quoting when allocating the memory to
> hold the resulting string.  "Transformation-based" buffer overflows
> (my hastily coined term) are starting to become more common.  If the
> transformation converts a double-quote character to a "&quote;", then
> an attacker could expand the original string by a factor of 6, which
> could have implications for the application itself *or* the back end.
>
> - Steve
>
>
> This email message and accompanying data may contain 
> information that is confidential and/or subject to legal 
> privilege. If you are not the intended recipient, you are 
> notified that any use, dissemination, distribution or copying 
> of this message or data is prohibited. If you have received 
> this email message in error, please notify us immediately and 
> erase all copies of this message and attachments.
>
> This email is for your convenience only, you should not rely 
> on any information contained herein for contractual or legal 
> purposes. You should only rely on information and/or 
> instructions in writing and on company letterhead signed by 
> authorised persons.
>
>
>
> MASTEK
> "Making a valuable difference"
> Mastek in NASSCOM's 'India Top 20' Software Service Exporters List.
> In the US, we're called MAJESCO
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Opinions expressed in this e-mail are those of the individual 
> and not that of Mastek Limited, unless specifically indicated 
> to that effect. Mastek Limited does not accept any 
> responsibility or liability for it. This e-mail and 
> attachments (if any) transmitted with it are confidential 
> and/or privileged and solely for the use of the intended 
> person or entity to which it is addressed. Any review, 
> re-transmission, dissemination or other use of or taking of 
> any action in reliance upon this information by persons or 
> entities other than the intended recipient is prohibited. 
> This e-mail and its attachments have been scanned for the 
> presence of computer viruses. It is the responsibility of the 
> recipient to run the virus check on e-mails and attachments 
> before opening them. If you have received this e-mail in 
> error, kindly delete this e-mail from all computers.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~