Thanks Richard
Yes, that was the first thing I told them.
Still, I wanted to see what's needed to pass the penetration testing without
getting those warnings, since this is the first I’d run into it. (you know,
best practices and whatnot ;-)
Thanks,
-Joel
On Mar 26, 2018, at 4:48 PM, Richard DeShong <richard@xxxxxxxxxxxxxx> wrote:
You could also reassure your client that since your db is FileMaker, and not
SQL, then the addition of sql-like text in the form fields does not do any
harm. That is why is says "... may be possible".
On 3/26/2018 3:41 PM, Joel Shapiro wrote:
Hi Steve
In what way do you “simply discard anything and everything else”?
Do you check for all possible submission types ( get / post / file / header
) on every single page?
On the “new_acct” page that was tested by my client, the page checks for —
and verifies & cleans — the appropriate POST submission but checks for no
other input. At least according to the penetration testing, however,
ignoring GETs, etc., is not enough…
Would the mere existence of some kind of check for each possible submission
type be sufficient to not produce these testing warnings?
e.g.
if ( !empty( $_GET ) ) {
// do nothing
}
?
And I don’t understand either how the page results could have been
“manipulated”. In my own testing, any GETs on that page are completely
ignored. I’ll see if I can get any more info from my client. They said the
testing was done by a 3rd party…
Thanks,
-Joel
On Mar 26, 2018, at 11:50 AM, Steve Winter <steve@xxxxxxxxxxxxxxxxxxx
<mailto:steve@xxxxxxxxxxxxxxxxxxx>> wrote:
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>
--
Richard DeShong
Logic Tools
510-642-5123 office
925-285-1088 cell
