Hi Joel, I presume that you are already doing the following, but just in
case...
Manipulated results means that they can get different results depending
on what query data they use to attack. This does not mean there is an
actual security issue, it just triggers a new set of attacks to try to
return useful info.
All of your environment tests (using isset() ), should return the same,
generic error. If any expected variables are not set, then you simple
have "bad parameters". You should not give any indication as to what is
missing in the response. I have seen many people suggest that at this
point you should just respond with your opening url. Essentially, your
app should see this as a fatal error.
This is different than testing the content of the parameters. In other
words, you should keep the environment tests separate from the content
tests. So you should not have:
If ( !isset( $thisText ) or empty( $thisText ) )
Hopefully that helps.
On 3/28/2018 10:27 AM, Joel Shapiro wrote:
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 <mailto: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
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 <mailto:fx.php_list-bounce@xxxxxxxxxxxxx>> on behalf of Steve Winter <steve@xxxxxxxxxxxxxxxxxxx <mailto:steve@xxxxxxxxxxxxxxxxxxx>>
*Reply-To:*<fx.php_list@xxxxxxxxxxxxx <mailto:fx.php_list@xxxxxxxxxxxxx>>
*Date:*Monday, March 26, 2018 at 2:51 PM
*To:*<fx.php_list@xxxxxxxxxxxxx <mailto: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:Steve Winter
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>
+371 2493 4441
steve@xxxxxxxxxxxxxxxxxxx <mailto:steve@xxxxxxxxxxxxxxxxxxx>
