Encode or Not?

  • Thread starter Thread starter Guadala Harry
  • Start date Start date
G

Guadala Harry

I'm storing the following string in a SS2K database (inserting and
retrieving via ADO.NET and stored procedures).

<style>.someStyle{color:#0000FF;font-family: Verdana, Arial, Helvetica,
sans-serif;font-size:28px;font-style:normal;font-weight:normal;}</style>

Is doing this dangerous? Should I encode it before writing it TO the
database and then decode it on retrieval?

Thanks.
 
Is doing this dangerous? Should I encode it before writing it TO the
database and then decode it on retrieval?
Click to expand...

Nothing really dangerous - but you should watch for ' (single) quotes.
 
Nothing really dangerous - but you should watch for ' (single) quotes.
<<<

Okay, what's the problem with single quotes?
 
Dangerous in what way? You're storing text data in a database. Nothing
dangerous about that. I have to wonder, though: Why not use an external CSS
file instead of a database?

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 
Guadala Harry said:
<<<

Okay, what's the problem with single quotes?
Click to expand...
A single quote is SS2k reserved character used to surround text string for
query purpose.

Example: select name from employees where employee_comment like 'microsoft's
product%'
The above example has the single quote between t and s, this will not pass
the Sql parser.

John
 
<<<

Okay, what's the problem with single quotes?
Click to expand...

SQL injection is the main thing...if this is user input and you're
dynamically building a SQL string by concatenating a string together with
this value, I could inject something with single quotes and then run
another query w/out you knowing (note this applies to any SQL work, not
your particular value). MSDN magazine has an excellent article in the
September issue on this; unfortunately it's not on the website yet

http://msdn.microsoft.com/msdnmag/

google on 'sql injection'...basically, i always use either parameterized
queries or stored procedures

normally i don't have a problem w/ storing html in the database; i prefer
to store data in its 'raw' format. so if this was input or this was the
original value, i would put that in the database. encoding/decoding i
leave to a specific app, but i prefer the 'original value' in the
database. that way i can tell what that data is and not have to remember
it was encoded, etc., i know this is the original, unaltered value...
 
Dangerous in what way<<
Concerned about possible sql injection - but we're dealing with css here so
wasn't sure if I should really be concerned or not - given that I'm not
accepting any SQL statements from the users.

This is simply a case of me being paranoid after reading a bunch of articles
on SQL injection... thought I'd get a quick take on me storing raw css in
the db... didn't think it would be a problem, but wanted to get at least
some verification.
I get more flexibility this way. Users specify preferences for background
color, font size, etc for their accounts on my site - which styles some of
the pages... store their preferences in the db... then I have a couple of
options (1) write out to a css file - as you suggest, or (2) inject the
entire <STYLE> tag (as a string) into the <HEAD> of the aspx file at runtime
when the user requests.

The end-result I'm after is styling the same page in multiple ways
(potentially one different way per user account).

It works... but I'd be interested in hearing any better ways to get the
end-result.

-G
 
I get more flexibility this way. Users specify preferences for background
color, font size, etc for their accounts on my site - which styles some of
the pages... store their preferences in the db...
Click to expand...

Understood, Harry. .

The best way to avoid SQL Injection attacks (and better architecture) is to
use Stored Procedures.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 
Back
Top