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

Groups > comp.lang.javascript > #24006 > unrolled thread

apostrophes

Back to article view | Back to comp.lang.javascript

Contents

  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

#24006 — apostrophes

I have a form into which users enter their names. The names get saved to 
a db. (Any apostrophes get encoded before being written to the db.)

The server side language is JScript in classic ASP.

When names get read back I use something like

Response.write("var name = '" + recSet("name").value + "';");

Which works fine until a name includes an apostrophe and the page will 
throw an error.

One way I've considered is backslashing a double quote eg

Response.write("var name = \"" + recSet("name").value + "\";");

which will only work until someone enters a name like
Stan "The Man" Longinidis

What's a better way of handling single/double apostrophes?

Andrew Poulos

[toc] | [next] | [standalone]

#24007

On Thu, 01 May 2014 16:15:12 +1000, Andrew Poulos wrote:
> Response.write("var name = \"" + recSet("name").value + "\";");
> 
> which will only work until someone enters a name like
> Stan "The Man" Longinidis
> 
> What's a better way of handling single/double apostrophes?

Just escape them including backslash characters. e.g.:

recSet("name").value.replace(/([\\'"])/g,"\\$1")

or:

recSet("name").value.toString().replace(/([\\'"])/g,"\\$1")

[toc] | [prev] | [next] | [standalone]

#24008

Andrew Poulos wrote:

> I have a form into which users enter their names. The names get saved to
> a db. (Any apostrophes get encoded before being written to the db.)
> 
> The server side language is JScript in classic ASP.
> 
> When names get read back I use something like
> 
> Response.write("var name = '" + recSet("name").value + "';");
> 
> Which works fine until a name includes an apostrophe and the page will
> throw an error.
> 
> One way I've considered is backslashing a double quote eg
> 
> Response.write("var name = \"" + recSet("name").value + "\";");
> 
> which will only work until someone enters a name like
> Stan "The Man" Longinidis
> 
> What's a better way of handling single/double apostrophes?

Sanitize input, escape output.

Assuming that the string value does not contain newline:

  Response.write(
      "var name = '"
    + recSet("name").value.replace(/[\\']/g, "\\\\$&")
    + "';");

or if it contains newline, (the equivalent of)

  Response.write(
      "var name = "
    + JSON.stringify(recSet("name").value)
    + ";");

Consider using a string builder instead of consecutive Response.write() 
calls.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#24009

Thomas 'PointedEars' Lahn wrote:

> Andrew Poulos wrote:
>> I have a form into which users enter their names. The names get saved to
>> a db. (Any apostrophes get encoded before being written to the db.)
>> […]
>> One way I've considered is backslashing a double quote eg
>> 
>> Response.write("var name = \"" + recSet("name").value + "\";");
>> 
>> which will only work until someone enters a name like
>> Stan "The Man" Longinidis
>> 
>> What's a better way of handling single/double apostrophes?
> 
> Sanitize input, escape output.
> 
> Assuming that the string value does not contain newline:
> 
>   Response.write(
>       "var name = '"
>     + recSet("name").value.replace(/[\\']/g, "\\\\$&")
>     + "';");

Nonsense.  I meant

  Response.write(
      "var name = '"
    + recSet("name").value.replace(/[\\']/g, "\\$&")
    + "';");

so as to escape backslashes and apostrophes with *one* backslash each.

I would also not assume that it is not possible to enter newline.  For 
example, if the input would be expected from an “input” element, an attacker 
could turn it into a “textarea” element or simply prepare their own request.
You need to consider such attack vectors both for sanitizing the database 
input and for escaping the output.

For database input, and preventing SQL injection, it would be best if you 
could use prepared statements.  For escaping output, and preventing XSS, 
(the equivalent of) JSON.stringify() would be best.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#24010

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

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#24016

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

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

[toc] | [prev] | [next] | [standalone]

#24023

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.

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

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.

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

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#24038

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web