Roland, This is a big question. Yes and maybe/doubtful.
Anytime you have users entering information into a DB, there are possibilities of them putting in unexpected content. Even a chat room, someone could enter in profanities and upset other users. Let's get a little more extreme here and talk about what you can do to a DB. I hate to give hacking lessons, but you might want to read up SQL injections where you insert SQL commands into data elements in a form that can do some bad things. The exact syntax varies depending on the db, and how you validate data. The important thing is to validate user input. If you are expecting an integer, make sure you get an integer. The hardest thing to trap for is free form text. You also need to keep in mind that your front end browser forms can be changed/reverse engineered to bypass client side data validation, so the validation has to be done server side. Let's say you are updating a note field in a table called mynote in mytable and it is coming in from a form in a field called @arg.myfield and you are updating record with mykey = 1234. The update command would be: Update mytTable set MyNote = @arg.myfield where myKey = 1234 Well you would expect @arg.myfield to be something like "This is my note" and when everything is evaluated, you get: Update mytTable set MyNote = 'This is my note' where myKey = 1234 All is good here, but change @arg.myfield to "Sucker' --" This will comment out the where clause and update every row in the table to: Update myTable set Mynote = 'Sucker' --' where mykey = 1234 Again it depends on the db, the fields being updated, and how input is validated as to your exposure. Don't forget you can append sql commands together with semicolons, so you could do Sucker'; drop table myTable -- Those unmatched quotes, dashes, and semicolons are bad news. Tango is pretty good about not letting the multiple commands through. You can cause other problems on websites with this method by commenting out where clauses on select statements joining tables, you could cause the result set to be hundreds of thousands of rows creating a denial of service problem because the server will be too busy to handle other requests. In a form you prompt for an expected index value @arg.myindex, and pull data from the db to create a report and expect a small dataset Select * from MyTable1, MyTable2, Mytable3 where Mytable1.myIndex = @arg.myindex and Mytable2.myindex = mytalbe1.myindex and Mytalbe3.myindex = mytable1.myindex Now you expect "123" in @arg.myindex, but lets say you get "123 or 1 = 1 --" When this evaluates, "or 1 = 1" always is true, the rest of the where statement is commented out, and you have a Cartesian join between the three tables. These are just a few examples, the possibilities are endless. The moral of the storey is to never trust data from the client, especially if they don't have to log in first. You also better make sure your password validation works: @arg.name = Troy @arg.pw = oops' or 1=1 -- Select count * from pwTable where username = @arg.name and pw = @arg.pw If @@resultset > 1 then Good to go Else Bad pw Endif Troy -----Original Message----- From: Roland Dumas [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 9:15 PM To: [EMAIL PROTECTED] Subject: Witango-Talk: Security question Have a client who is asking questions about security. Specifically, if there is a field that is entered via web form and then placed in a database, is there the possibility that evil scripts can be submitted that will do evil things either to the database or to a user reading the content of that column? ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
