[fx.php_list] Re: [OFF] "SQL injection may be possible" ?

  • From: Joel Shapiro <info@xxxxxxxxx>
  • To: fx.php_list@xxxxxxxxxxxxx
  • Date: Wed, 28 Mar 2018 10:27:28 -0700

Thanks for the link, Chris.  That’s interesting.

The curious part about my situation is that GET params are not acknowledged on 
this page in any manner, so I can’t see how the testing produced “manipulated 
page results”.  

It seems equivalent to loading http://fx.iviking.org vs ;
http://fx.iviking.org?abc=123 ;

Best,
-Joel


On Mar 26, 2018, at 1:19 PM, Chris Moyer <cmoyer@xxxxxxxxxxxxxx> wrote:

Steve,
Regarding the referenced Boolean conditions, take a look at this for a more 
comprehensive explanation:
 
https://www.owasp.org/index.php/Blind_SQL_Injection ;
<https://www.owasp.org/index.php/Blind_SQL_Injection>
 
I am also a bit confused by the feedback that you’ve been given - in what way 
were "the page results [] successfully manipulated using the boolean 
conditions…”…? A new account was created with undesired credentials? The 
screen output an error? The content of the URL was saved in the DB somewhere?
 
 
Chris
 
From: <fx.php_list-bounce@xxxxxxxxxxxxx> on behalf of Steve Winter 
<steve@xxxxxxxxxxxxxxxxxxx>
Reply-To: <fx.php_list@xxxxxxxxxxxxx>
Date: Monday, March 26, 2018 at 2:51 PM
To: <fx.php_list@xxxxxxxxxxxxx>
Subject: [fx.php_list] Re: [OFF] "SQL injection may be possible" ?
 
Hi Joel <>
 
I’m not sure I agree with Bev’s approach - it’s certainly one way to ensure 
that you’re not processing any unexpected input, however I would be inclined 
to take an alternative course.
 
Rather than ‘fail fatally on all unexpected input’ (which is what a white 
screen ends up appearing to be), I tend to only process explicitly expected 
input (be that get / post / file / header) and simply discard anything and 
everything else. In that way the application functions as desired utilising 
the expected input, will fail (gracefully) if there is any expected input 
missing (e.g. warning message to that effect, offering a way forward for the 
user), and anything else that’s thrown at it will be simply ignored.
 
I am also a bit confused by the feedback that you’ve been given - in what way 
were "the page results [] successfully manipulated using the boolean 
conditions…”…? A new account was created with undesired credentials? The 
screen output an error? The content of the URL was saved in the DB somewhere?
 
Cheers
Steve


On 23 Mar 2018, at 22:43, Joel Shapiro <info@xxxxxxxxx 
<mailto:info@xxxxxxxxx>> wrote:
 
Hi Bev
 
So you check for GET on every single page, whether you’re expecting GET 
params or not?

Would a simple  if ( !empty( $_GET ) )  be sufficient?
 
And would returning a blank page satisfy the penetration testing so that 
there won’t be any warnings?  It sure seems like that would “successfully 
manipulate the page results”.  Or does the testing just look to make sure 
that there is some kind of GET trapping?

Do you check for POST on every single page too?
 
(Does everyone else always do this, universally??)

Thanks,
-Joel



On Mar 23, 2018, at 2:27 PM, Beverly Voth <beverlyvoth@xxxxxxxxx 
<mailto:beverlyvoth@xxxxxxxxx>> wrote:

YES! You specifically trap for the GET. Halt at the point, post a 
“~%€€{#%<36$?788 you spammer/hacker” if desired. Mostly, I halt and go to a 
blank. 

Sent from miPhone

On Mar 23, 2018, at 5:17 PM, Joel Shapiro <info@xxxxxxxxx 
<mailto:info@xxxxxxxxx>> wrote:


Hi all

I was recently contacted by an old CWP client that they’d had some 
penetration testing done on their server(s) by a 3rd party, and got a 
warning on one of my CWP pages, as attached.

This is something I built many years ago… 

It’s a simple <form> page that submits to itself.  It checks for the 
appropriate $_POST submission and then verifies and cleans the data before 
sending it to FM.

It doesn’t do any kind of check for $_GET (or $_REQUEST) submissions, nor 
is it set to process any GET parameters — but it seems that that’s what 
this “SQL injection may be possible” warning is doing.

In the “Other Information” section, it says: 
    “The page results were successfully manipulated using the boolean 
conditions [query AND 1=1 -- ] and [query OR 1=1 -- ]"
which I don’t understand, since there’s nothing on the page to deal w/ GET 
params, and my testing shows no differences (or “manipulations”).

I’ve never run into this before.  Does anyone have any recommendations for 
getting rid of the warning?  Do I need to check for GET even though I 
don’t expect nor want any GET values?

TIA,
-Joel


<sqlInjPossible.png>




 

 
Steve Winter
+371 2493 4441
steve@xxxxxxxxxxxxxxxxxxx <mailto:steve@xxxxxxxxxxxxxxxxxxx>

Other related posts: