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> 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>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
