php-general Digest 29 Apr 2010 10:46:06 -0000 Issue 6718
Topics (messages 304737 through 304749):
Re: Security/Development Question
304737 by: Andre Polykanine
304738 by: Paul M Foster
304739 by: Robert Cummings
304740 by: Programming Guides
304741 by: Karl DeSaulniers
304743 by: Ross McKay
304744 by: Ashley Sheridan
Re: CURL cannot connect to URL - IP address - after successful connection
304742 by: ioannes.btinternet.com
304745 by: Tommy Pham
304749 by: Gary .
Malware Question
304746 by: Ashley Sheridan
304747 by: Daniel Brown
304748 by: Ross McKay
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
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 <dsto...@shh.org>
To: php-gene...@lists.php.net <php-gene...@lists.php.net>
Date: Wednesday, April 28, 2010, 11:54:56 PM
Subject: [PHP] 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
--- End Message ---
--- Begin Message ---
On Wed, Apr 28, 2010 at 04:54:56PM -0400, 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. 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
>
Holy crap!
There's a very good reason why your security application is blocking
their software. You have no control over these SQL strings, and
injection could occur if only by accident if you're not in control of
them. The only thing I can imagine worse than passing a SQL query around
in a POST variable is passing it around in a GET variable.
Sometimes I wonder where programmers like this come from. I'm not that
good with security, but even I wouldn't do this.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
On Wed, Apr 28, 2010 at 4:02 PM, Andre Polykanine <an...@oire.org> 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 <dsto...@shh.org>
> To: php-gene...@lists.php.net <php-gene...@lists.php.net>
> Date: Wednesday, April 28, 2010, 11:54:56 PM
> Subject: [PHP] 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
--- End Message ---
--- Begin Message ---
Hi all,
I am learning PHP and found this problem to be interesting.
I personally would never do this myself. All the manuals I have read
strictly prohibit this type of behavior.
Wouldn't you just have them run the queries on their end and send you
the results instead of the query itself?
Curious to see what would be the best scenario for this when you have
a third party involved.
What would be the best way to have them format their data to send you?
Best,
Karl
On Apr 28, 2010, at 4:23 PM, Programming Guides wrote:
On Wed, Apr 28, 2010 at 4:02 PM, Andre Polykanine <an...@oire.org>
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 <dsto...@shh.org>
To: php-gene...@lists.php.net <php-gene...@lists.php.net>
Date: Wednesday, April 28, 2010, 11:54:56 PM
Subject: [PHP] 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
Karl DeSaulniers
Design Drumm
http://designdrumm.com
--- End Message ---
--- Begin Message ---
On Wed, 28 Apr 2010 16:54:56 -0400, "David Stoltz" wrote:
>[...]
>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.... [...]
Unless they're storing the SQL queries so that they can show them later
on, e.g. as text in a forum post, I think you have a major WTF on your
hands! Please submit here!
http://thedailywtf.com/Contact.aspx
:)
--
Ross McKay, Toronto, NSW Australia
"The chief cause of problems is solutions" -Eric Sevareid
--- End Message ---
--- Begin Message ---
On Thu, 2010-04-29 at 08:49 +1000, Ross McKay wrote:
> On Wed, 28 Apr 2010 16:54:56 -0400, "David Stoltz" wrote:
>
> >[...]
> >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.... [...]
>
> Unless they're storing the SQL queries so that they can show them later
> on, e.g. as text in a forum post, I think you have a major WTF on your
> hands! Please submit here!
>
> http://thedailywtf.com/Contact.aspx
>
> :)
> --
> Ross McKay, Toronto, NSW Australia
> "The chief cause of problems is solutions" -Eric Sevareid
>
You could always try crafting your own query and attempt to insert
something of your own. If they complain after that you've broke their
system, you'll be able to tell them that it really wasn't that secure in
the first place.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
I think the answer is: ISPs have a different range of addresses from
host providers, so it is possible to block requests from host servers,
so from scripts.
John
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: ioan...@btinternet.com [mailto:ioan...@btinternet.com]
> Sent: Wednesday, April 28, 2010 7:03 AM
> To: 'PHP'
> Subject: Re: [PHP] CURL cannot connect to URL - IP address - after
successful
> connection
>
> I think the answer is: ISPs have a different range of addresses from host
> providers, so it is possible to block requests from host servers, so from
> scripts.
>
> John
>
That's possible but very unlikely in your case. Since you were to able to
get the necessary information on the 1st request, but failed on subsequent
means it has an anti-bot mechanism in place. Bypassing anti-bot requires
in-depth reverse-engineering of the targeted site.
Regards,
Tommy
--- End Message ---
--- Begin Message ---
On 4/25/10, ioan...@btinternet.com wrote:
> I can return a target page - once, but then on refresh within a few
> hours the script curl_error is that it cannot connect to the host and
> return is empty.
Failed to connect to host is a pretty strange error if they're doing
anything regarding cookies and so on, IMO - I think I'd expect at
least a connection to be established before they decide they don't
like you. Have you used curl's --trace & --trace-ascii options?
--- End Message ---
--- Begin Message ---
Hi all,
This isn't exactly a PHP question, but I don't know anyone else with the
collected smarts of this list. Basically, a site I built and am managing
has been identified by Google as a source of malware. Now, I've been
over the source code with a fine-toothed comb and found nothing, I've
gone over the HTML output for anything suspicious, checked ever single
Javascript file out, looked to see the server headers are correct and
aren't malformed, checked the .htaccess is as expected and have run the
site against the unmask parasites website which found no problems except
the 'suspicious' listing which Google has given it.
The Google webmaster tools tell me nothing more than 'Of the 2 pages we
tested on the site over the past 90 days, 2 page(s) resulted in
malicious software being downloaded and installed without user consent.'
It won't tell me what pages, although it tells me that the malicious
software is hosted on one domain and tells me what it is. Needless to
say I can't find that domain string anywhere in the code. I can't find
any hidden iframe tags or hidden Javascript eval() statements.
Basically now, although this is totally beyond my control, the owner of
the site is expecting me to get this sorted asap. I want to, and have
spent the entire day today looking at it, but have really come to the
point where I'm coming unstuck. I can find nothing wrong with the site
at all.
Does anyone have any helpful advice for this sort of thing? Tools that I
can use to check out the site with, or any bit of information that I can
use to fix this? I can give the URL of the site to anyone off-list if
they wish to check it out.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Wed, Apr 28, 2010 at 19:50, Ashley Sheridan <a...@ashleysheridan.co.uk>
wrote:
>
> The Google webmaster tools tell me nothing more than 'Of the 2 pages we
> tested on the site over the past 90 days, 2 page(s) resulted in
> malicious software being downloaded and installed without user consent.'
> It won't tell me what pages, although it tells me that the malicious
> software is hosted on one domain and tells me what it is. Needless to
> say I can't find that domain string anywhere in the code. I can't find
> any hidden iframe tags or hidden Javascript eval() statements.
Ash, let me know off-list what the domain is and I'll try to do a
scan on it from here this evening.
--
</Daniel P. Brown>
daniel.br...@parasane.net || danbr...@php.net
http://www.parasane.net/ || http://www.pilotpig.net/
We now offer SAME-DAY SETUP on a new line of servers!
--- End Message ---
--- Begin Message ---
On Thu, 29 Apr 2010 00:50:52 +0100, Ashley Sheridan wrote:
>This isn't exactly a PHP question, but I don't know anyone else with the
>collected smarts of this list. Basically, a site I built and am managing
>has been identified by Google as a source of malware. [...]
Check the sites you link to. We had a client who had some links to
websites that had been turned into malware sites; just having the links
to the malware sites was enough to mark that website as a source of
malware.
We had to advise the client to only add links for actual people they've
had contact with, not just people who send them email invitations to
exchange links.
--
Ross McKay, Toronto, NSW Australia
"I really hope they find a nice place,
I hope they find it somewhere,
I HOPE THEY GO AWAY"
- Everclear
--- End Message ---
