Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #24038

Re: apostrophes

Show all headers | View raw

On 5/3/14, 11:00 AM, Evertjan. wrote:
> Richard Damon <Richard@Damon-Family.org> wrote on 03 mei 2014 in 
> comp.lang.javascript:
> 
>> On 5/1/14, 7:34 AM, Evertjan. wrote:
>>> Andrew Poulos <ap_prog@hotmail.com> wrote on 01 mei 2014 in
>>> comp.lang.javascript:
>>>
>>>> What's a better way of handling single/double apostrophes?
>>>
>>> Never heard of a "double apostrophe" btw. ;-)
>>>
>>> I replace the [single] apostrophe ' with a single back quote ` before
>>> storing
>>> them into a database, and replace it back on printing.
>>>
>>> On a debugging level, these string fields look acceptable.
>>>
>>> This way searching the database is far easier than having multiple
>>> characters, also because wildcard searches are more inuitive.
>>>
>>> You wouldn't want to store strings with apotrophes in a sql/access-type
>>> database anyway because of the danger of SQL Injection Attacks.
>>>
>>> [SQL Injection Attacks could be prevented by using a parametric method,
>>> but I usually don't bother with that.]
>>
>> The way to stop Injection Attacks is to routinely sanitize data sent to
>> the database by escaping the characters with the function provided by
>> the database layer for that purpose (like mysql_real_escape_string), or
>> to use prepared statements. 
> 
> No the first is not "the way". 
> "The way" depends on your local requirements and who has access.
> There is no sense in defence if you are the only one using the function,
> as you have rights to destroy the whole database anyway.

I have seen many problems caused by arguments like this. While it is
true that it can make sense to not put the effort in to deal with
obscure threat vectors in the case where you are starting from a "safe"
environment, that doesn't mean that it is good to not know about and use
the "right" methods when they are applicable. There is also the issue
that it is not uncommon for "toy" applications to later get re-purposed
and if short cuts were taken, this action really requires a lot more
effort (which might end up being skipped due to external pressures).

I can understand a toy program not doing any (or very limited)
sanitation. It is quick and easy, and you KNOW that if you need to
upgrade the use case there needs to be changes.

Using a incomplete sanitation is much more problematical. One, it lends
a false sense of security, you have handled the big case, but not all
the cases. The code might get a pass in a security review as it looks
like the problem has been taken care of, but it hasn't.

Two, it gets you into bad habits. You develop an internal idiom for
sanitation that is incomplete, so may be tempted to use it in cases
where it is not applicable.

Considering that the "official"/"right" way is no more complicated to
write then the "simple" way, there is very little reason to not use the
"right" way. The only valid excuses that I can think of are 1) It isn't
provided to me (which I would seriously doubt), or 2) I never learned
about it (to which the response of being shown a better way should be to
think of changing in the future).

> 
>> You method is incomplete (unless you didn't
>> describe it fully) as, for example, if a name is entered with a trailing
>> \, and you are just building up a string for your query, that \ will
>> "escape" the ending quote in your statement and your statement will fail
>> due to a syntax error.
> 
> Nonsense, an thrown error is a dirty but fine defense against injection.
>  
Handling thrown errors, in my experience, is not always an easy task,
and generally requires an attention to details not apt to be present in
the code that uses "ad-hoc" sanitation. The issue is that frequently
several interrelated operations are done together, with interrelations
between tables to maintain, and the skill to keep these in sync in the
presence of unexpected errors (like wrapping the operations in a
transaction), tends to also lead to using the "proper" sanitation methods.

>> Note that the database won't have the escape sequences stored in them
>> (\') but only the character that was escaped ('), thus you actually have
>> LESS code, 
> 
> True, I am quite happy with my way, though.
> 
> I hate "better way" questions. 
> Programming is also art and hobby, 
> so while you can learn from others,
> you don't have to share thier convictions,
> silly or otherwise.
> 
Please note, that I never said you couldn't use your method, only
pointing out the problems with it. The OP had a problem, YOU provided an
ad-hoc solution, I pointed out a more complete solution.

> Names shouldn't allow backslashes anyway. All not-allowed characters should 
> be filtered uot serverside anyway, like integer strings should be converted 
> to real integers, etc.
> 

One point of observation, it is much safer to "White list" allowed
characters rather than "Black List" bad characters, as it is easier to
make sure you have blocked everything that gives you problems.

>> as their is no need to do any conversion on reading from the
>> database, it will always give you back what you intended to write.
> 
> My intensions are mot the point here, methinks,
> this is about user input.
> 
> Users only accidentally write what they intend to write, 
> is my experience.
> 

Back to comp.lang.javascript | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

apostrophes Andrew Poulos <ap_prog@hotmail.com> - 2014-05-01 16:15 +1000
  Re: apostrophes JJ <duh@nah.meh> - 2014-05-01 15:15 +0700
  Re: apostrophes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-01 10:28 +0200
    Re: apostrophes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-05-01 10:42 +0200
  Re: apostrophes "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-05-01 13:34 +0200
    Re: apostrophes Richard Damon <Richard@Damon-Family.org> - 2014-05-03 10:00 -0400
      Re: apostrophes "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-05-03 17:00 +0200
        Re: apostrophes Richard Damon <Richard@Damon-Family.org> - 2014-05-03 12:54 -0400

csiph-web