Security/Development Question
in [General]
|
From: "David Stoltz" on 28 Apr 2010 16:54 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
From: Robert Cummings on 28 Apr 2010 17:18 David Stoltz wrote: > 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. Run... scream and run... to the server and get it off :) Ok, maybe it's not that bad... read on for more! > Now, the app is > SSL protected, and they claim the queries are not executed - only > inserted into the database to be used later. TO BE USED LATER??? AS IN EXECUTED? It doesn't matter if you stave off an injection attack till a week from today, it still will screw up your database. > They also said it's > protected by the ASP.NET framework authentication....not sure about any > of that. Me neither... but I'd still be worried. Maaaaaaaaaaaaaaaaaybe the query was created on the server and a checksum or hash was createwd to ensure no tampering with the query. But still, I would worry that you are revealing information about your database to the public. No information leakage is the best kind of leakage. > 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? You are right. This is shoddy practice. > See below for the stuff they are passing in the POST (obvious things > like table names have been changed): > > /wEWBQLciq6UBwLEhISFCwLa2223bD3wK3+56LBAKc37iSDEsHMFjpB6o1vHld19wT+Tt3sY > 8E The above portion is probably the checksum / hash to detect tampering... AKA if I understand correctly... the "ASP.NET framework authentication". > &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 Nice of them to share the database structure with the public. The query may be secure from tampering, but it is terrible practice to reveal internal design to the public. Although, admittedly in this day and age of open source applications like drupal/joomla/mediawiki/other the public knows your database structure unless you choose an offbeat table prefix :) Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: tedd on 29 Apr 2010 09:05 At 4:54 PM -0400 4/28/10, David Stoltz wrote: >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? David : First, you are not wrong. Second, that's exactly the type of security risk you want to protect yourself from. Third, never trust anything coming from client-side (i.e., POST, GET, or COOKIE). Now, they (the vendor) can throw all the layers of confusion/nonsense (it's SSL, APS.NET, or will happen later) on this as they want, but the point remains this is permitting client-side access to a database and that is NOT good. Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com
|
Pages: 1 Prev: Two color rows in table inside while iteration Next: Malware Question |