At 12:37 PM 3/10/2011, Claudio Nanni wrote:
>Hi there,
>Yes I think its actually a pattern a few hundreds million sites solved
>already :)
Great. How did they do it? :)
>And any way to encrypt (scramble)the http get string would do. But my
>question is , are you afraid of sql injection?
I'm using parameterized queries and validating user input so SQL injection
shouldn't be a problem.
I just don't want to give the hacker any more useful information than
necessary. Let's say I have a Document_Id column and the url is
www.mydocuments.com/public?docid=4
to retrieve document_id=4, I don't want someone to write a program to
retrieve all of my public documents and download them. I want them to go
through the user interface.
The private documents of course need a user name and password to access
them, but public documents do not require passwords.
So hashing or encrypting the id column will make the id's non-contiguous
and impossible to guess.
Mike
>How do fear your db would be violated?
>On Mar 10, 2011 6:13 PM, "mos"
><<mailto:mos99@stripped>mos99@stripped> wrote:
> > I want to bounce some ideas off of MySQL developers that use it for web
> > development. Maybe I'm a little paranoid, but when dealing with the
> > Internet, I want to make my web app as secure as possible. I'm hoping some
> > of you can offer me some ideas in this respect.
> >
> > I am building a web application that uses MySQL 5.5 with Innodb tables and
> > I don't want the user to see the actual primary key value on the web page.
> > The primary key could be the cust_id, bill_id etc and is usually auto
> > increment. This primary key can appear in the url and will be used to pull
> > up a record and display it on the web page.
> >
> > So I need some efficient way of 'cloaking' the real primary key so a
> hacker
> > won't try to generate random values to access info he shouldn't have
> access
> > to. How do most web sites handle this?
> >
> > I thought of using UUID_Short() for the primary key instead of an
> auto-inc,
> > and this isn't really random. It generates near sequential numbers
> based on
> > time.
> >
> > So I need a way of encrypting the cust_id before sending it to the web
> > page. The user can bookmark this page in his browser so I need to be able
> > to decrypt it back to the real cust_id to retrieve the data. Doing the
> > encryption and decryption is easy enough for me to do on the web server.
> >
> > I have tried Hex(AES_Encrypt(Cust_Id,'secret')) and this works fine except
> > the string is very long at 64
> > characters. hex(DES_Encrypt(Cust_Id,'secret')) generates a smaller string.
> >
> > Another alternative is to store an MD5 hash value of Cust_Id in the table
> > under a different column "Cust_Id_Hash" and display that on the web
> > page. So the table joins would still use Cust_Id and Cust_Id_Hash would be
> > used only as a lookup when communicate with the web page. But Innodb's
> > ability to store large random strings will slow down inserts and will
> > consume more disk space.
> >
> > What is the best way to solve the problem? I don't want to re-invent the
> > wheel because I'm sure this problem has been solved by other web
> > developers. Maybe an efficient solution is staring me in the face, so I'm
> > open to some suggestions. :-)
> >
> > TIA
> > Mike
> >
> >
> > --
> > MySQL General Mailing List
> > For list archives:
> <http://lists.mysql.com/mysql>http://lists.mysql.com/mysql
> > To unsubscribe:
> <http://lists.mysql.com/mysql?unsub=1
> >
