On Wed, Apr 28, 2010 at 4:02 PM, Andre Polykanine <andre@xxxxxxxx> wrote: > Hello David, > > I'm not a PHP god but I would never ever do such things.I can't even > imagine what can be the reason of passing an SQL query through a > form... > -- > With best regards from Ukraine, > Andre > Skype: Francophile; Wlm&MSN: arthaelon @ yandex.ru; Jabber: arthaelon @ > jabber.org > Yahoo! messenger: andre.polykanine; ICQ: 191749952 > Twitter: m_elensule > > ----- Original message ----- > From: David Stoltz <Dstoltz@xxxxxxx> > To: php-general@xxxxxxxxxxxxx <php-general@xxxxxxxxxxxxx> > Date: Wednesday, April 28, 2010, 11:54:56 PM > Subject: Security/Development Question > > Hi folks, > > > > This isn't really a PHP question per se, but could apply to any > language... > > > > I have a public facing web server, which we have a software component > that helps protect us from SQL Injection, and the like. > > > > We recently have added a very small web application that is vendor > supported. They said it's not working, so I investigated. I found that > our software protection was blocking their pages because they are > actually passing entire SQL queries in their form POSTs. Now, the app is > SSL protected, and they claim the queries are not executed - only > inserted into the database to be used later. They also said it's > protected by the ASP.NET framework authentication....not sure about any > of that. > > > > My concern is passing SQL queries in this way is not best practice - am > I wrong? Please let me know how you would react to this? > > > > See below for the stuff they are passing in the POST (obvious things > like table names have been changed): > > > > /wEWBQLciq6UBwLEhISFCwLa2223bD3wK3+56LBAKc37iSDEsHMFjpB6o1vHld19wT+Tt3sY > 8E&CRITICAL_RESULT&on&Declare @critical varchar (40) > > set @critical = (select top 1 code from table where id = 'clr7' and > thename = 'critical') > > > > sELECT > > OPR_SECD.REC USER_REC_NO, > > RESULT.*, > > (SELECT RESULT_DESC FROM table WHERE code = RESULT.RES_MSTR_CODE) > [DESC], > > [ORDER].*, > > (SELECT VALUE FROM table WHERE this_CODE = 'Email' AND USER_REC = > OPR_SECD.RECNUM) MBMD_EMAIL, > > OPR_SECD.OPR_INITIAL > > FROM RESULTING LEFT JOIN [ORDER] ON RESULTING.ORDER_REC = > [ORDERBY].RECNUM > > LEFT JOIN OPR_SECD ON [ORDER].DR_CODE = OPR_SECD.XREF_CODE > > where (RESULT.FLAG_TEXT) = @critical AND RESULT.REC = @ID&Save > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > I can't say that I agree with this design but it is certainly possible to prevent against crafted POST data. I think in your particular case they might be doing that judging by the presence of the hash at the beginning of the POST data (although that could be anything... I'm just guessing). A general way to prevent against crafted POST data is to have a session or even a page secret key. The key is hashed with the value which is then written to the (I suppose) hidden form field. When the POST data comes back it's hashed with the key and checked against the hash in the POST. So.. yes it's possible to prevent from crafting the POST data but the design is still crappy; I wouldn't do it. -- Viktor http://programming-guides.com
