Hi, Matt,
A search on Google should give you some of answers.
Prepared statements are supposed to take care of this. However, don't forget
that you will have the same problem when retrieving the data from the
database. For example, if you managed a book database and get the string
"O'Reilly" for the publisher field and try to display it in a form input
field of type text, you might get this :
<input type='text' name='publisher' value='O'Reilly'>
and the result will not be what you're expecting ! So you will have to
escape again at least ', " >, < and &.
Pierre-Yves
-----Message d'origine-----
De : A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]De la part de Matt
Penner
Envoy� : vendredi 21 septembre 2001 17:31
� : [EMAIL PROTECTED]
Objet : Re: replacing apostrophes
Wow, that's interesting. I haven't had the time to scour the new 1.4 docs
yet. Thanks Pierre, it's nice to have someone correct your work before you
have to 'find' the implemetation problems yourself.
I suppose that during migration I could write a 1.3 program to decode all
the
data and place it into temporary tables and then run a 1.4 that would encode
it
all back. Of course this requires recompiling all my programs unless I use
a
custom encoder class which calls the actual encoding method.
Anyway, I've looked through the prepared statement specs and all and
although I
know it takes care of apostrophes and quotes I haven't found any references
to
that behavior at all. My only concern is that does it escape all non-alpha
numeric characters? With all the databases out there there are quite a few
of
database specific escape characters that could be used in user input forms
to
undermine the security of the application.
Can anyone shed a little light on this for me or let me know of a place that
has a concrete spec of what the prepared statement set methods are doing
exactly?
Thanks!
Matt
Quoting Pierre-Yves Saumont <[EMAIL PROTECTED]>:
> >Another alternative is to use the URLEncoder and URLDecoder classes.
> This
> >takes all non alpha-numeric characters not including periods and
> changes
> them
> >into their HTML equivalent. This would convert any possible character
> or
> >string that would cause a problem with databases such as escape
> characters
> and
> >such.
>
> Beware that this might not be portable. Default (and only available)
> encoding scheme until version 1.3 is on byte ASCII. In 1.4 beta 2,
> default
> has been changed to UTF8. So, data encoded with version 1.3 would have
> to be
> decoded in 1.4 specifying a non default scheme. However, such programs
> will
> not work with version 1.3, which make the switch from 1.3 to 1.4 very
> problematic. One possibility would be to test for Java version and act
> accordingly. Such a program would only compile under 1.4 but should run
> in
> 1.3. Sun is aware of this problem, but put it in the "ease of use"
> category,
> which makes me think it could really stay like this in final release.
> The
> reason is obviously that such encoding is not intended for persistent
> data
> and should not be used in that case. Once again, the secure solution
> is
> prepared statements.
>
> Pierre-Yves
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources:
> http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
