RE: Witango-Talk: Security question
Hi Roland, This is very unlikely; it is more likely that they would try to add sql statements in the input field. First of the data type constraints off the database field would probably either prevent the saving of the offensive code and will most likely truncate it. Even if there is supposedly evil script saved in the data, when pulled from the database it is not being viewed in a manner that will execute it. Plus, most firewalls and antivirus servers and client will block in the unlikely event that the script is intact. I have had this attempt happen to me, but the hacker didn't realize that the form didn't save to the database but was just emailed to me. I have view the code in Outlook without any issues. Ben Johansen -Original Message- From: Roland Dumas [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 8: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
RE: Witango-Talk: Security question
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
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
RE: Witango-Talk: Witango 5.5 Java
Hey Scott, thanks for the advice. Yes, I agree we need to do a great deal more testing and your points are valid. Since we're playing with the 30 day trial I wanted to do something quick and dirty to see if there was a significant difference. I didn't see any and honestly expected to. I was just wondering if my expectations were unrealistic in this test. Obviously they are. We'll continue testing by converting some intensive programs over to Java and compare the time on those as well. Thanks for the feedback. -Original Message- From: Scott Cadillac [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 4:38 PM To: [EMAIL PROTECTED] Subject: Re: Witango-Talk: Witango 5.5 Java Hi Gene, I hate to say it, but I think you need to put more effort into your speed test than just a For loop. What about the difference between how Java code handles datasources, and how Java code manages large arrays in memory and how Witango does these things? In a production environment, these two points have been the two main stumbling blocks when it comes to seriously comparing Witango to other development platforms - as far as speed goes. Of course, there are also other points to consider as well. I would also test for performance under a load of several simultaneous requests. Say, 20 requests against each platform - what's the difference then? Plus I would make sure your "design" approach can live with the Variable scoping rules you'll find in other platforms. After you get through the above, then you might have a close to conclusive answer to your question. Good luck Scott Cadillac, XML-Extranet ~ 403-254-5002 ~ [EMAIL PROTECTED] Well-formed Programming in C# ASP.NET, Witango and XML For Hire ~ http://xmlx.ca/forhire IExtranet ~ http://IExtranet.net Weblog ~ http://xmlx.ca Forums ~ http://forums.xmlx.ca Knowledge Base ~ http://kb.xmlx.ca P.O. Box 69006 RPO Bridlewood SW Calgary, Alberta Canada T2Y 4T9 -Original Message- From: "Wolf, Gene" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Tue, 21 Sep 2004 16:13:18 -0400 Subject: Witango-Talk: Witango 5.5 Java >OK, I think I am confused. *laughs* We're playing with Witango 5.5 > and one of my folks put in a lot of work and got Witango 5.5 running > on an older server box. I wanted to kick the tires on this during the > 30 day trial to see if compiled Java code was any faster than normal > Witango code. So code was written to go through a for loop 100,000 > times and display the time the loop began and the time that it ended. > >In normal Witango code the loop took on average 21-22 seconds. Under > compiled Java the average time was 19 seconds. We understand that we're > running on two different boxes with different loads but I would have > expected a much greater difference in execution speeds. Has anyone seen > any major improvement in going to 5.5 and compiled Java. I'm wondering > if this is even worth the trouble if the speed differences and that > small. > >Any feedback or thoughts are appreciated. > ___ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
