Home page logo
/

webappsec logo WebApp Sec mailing list archives

RE: SQL Injection
From: "V. Poddubniy" <vpoddubniy () mail ru>
Date: Wed, 9 Jun 2004 19:04:08 +0400

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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]