Re: Security for web site accessing i via IWS

Thanks Jon and Sam and Pete.
Interesting and useful resources. Most of the inputs I'm concerned with for this project are expected to be numerals only and of very specific lengths (bank account, routing numbers, phone numbers). My DigitsOnly service program (returns only numeric characters from a string) will get a workout, and the email input test should reject anything with a semicolon or imbedded space. I'll just be diligent about validating everything before any damage can happen.

Much appreciated!
-- Michael

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Tuesday, February 03, 2015 12:12 PM
To: Web400@Midrange. Web400
Subject: Re: [WEB400] Security for web site accessing i via IWS

The major thing you can do is to make sure that the value supplied
conforms to the anticipated input. e.g. if it is supposed to be a number
then it must be a number.

An injection attack requires as a minimum a semi-colon in the string
because to be effective it has to terminate your statement so that it can
start a new nasty one. It would also normally have a - marker at the end
to make any of the original SQL a comment.

There's a lot of stuff on the web on the topic - this one is aimed at SQL
Server but is a fairly good description of the basic problem and how to
defend against it. It talks too about the use of parameterized queries and
the limits to the defence that they provide.

http://www.codeproject.com/Articles/9378/SQL-Injection-Attacks-and-Some-
Tips-on-How-to-Prev


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Feb 3, 2015, at 11:50 AM, Koester, Michael <mkoester@xxxxxxxxxxxxx>
wrote:

Thanks Jon.
I'll make a prominent comment in the maintenance notes block to caution

anyone that messes with this code in the future to be aware of that (and
wish it well).

If I get wind of any tool that scrubs the input strings to give it a

more robust layer of protection from inexperienced developers that follow,
I'd add that in too.

-- Michael

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Jon
Paris
Sent: Tuesday, February 03, 2015 11:36 AM
To: Web400@Midrange. Web400
Subject: Re: [WEB400] Security for web site accessing i via IWS

As long as you only use static SQL and/or SQL with parameter markers
you do not have to worry about SQL injection attacks.

If you start building SQL statements dynamically then you need to
take defensive action.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Feb 3, 2015, at 11:23 AM, Koester, Michael
<mkoester@xxxxxxxxxxxxx>
wrote:

Thanks Pete.
Do you know of any RPG/SQL tricks to trap SQL injection? My
embedded

SQL uses static SQL statements only (currently), and I'm validating
the inputs by testing fields that should be numeric for numerals
only, email addresses for permitted characters only (no blanks or
back-slashes, etc.) and proper acct@domain structures...

But I do not know anything about CSRF and XSS.
Not being Java/PHP-proficient, I humbly admit to limitations.
Any suggestions would be greatly appreciated.
-- Michael

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Pete
Helgren
Sent: Tuesday, February 03, 2015 10:44 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Security for web site accessing i via IWS

Michael,

If you are current on PTF's then any SSL concerns should be

mitigated.

The greatest points of exposure are SQL injection, CSRF and XSS.
SQL injection would be handled at the server (which I would guess
you are aware of) and the CSRF and XSS vulnerabilities would be
handled by you sanitizing all the inputs and outputs from your web
service, again, stuff you are probably familiar with. Since most
of my stuff is using Java on the backend on IBM i, I rely on the
ESAPI libraries to

check and sanitize.

With RPG your work will be more manual.

If you are using SSL both for the web site and web services called,
then your data should remain safe in transit. The session
management stuff recommended by Nathan is sane as well. I haven't
worked with web services for a while but I do remember the
authentication step was key (and maybe overly complicated in my

apps).

I don't see any glaring holes in what you propose.

Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java

On 2/3/2015 9:22 AM, Koester, Michael wrote:

Not offended here. Realities of a small company and small IT team
often

get in the way of what's best. I am the only one here that knew
the AVR.net application. I used past-tense deliberately, because
among all the other skills I need to learn and use, my AVR.net is
seldom used. It would take me a lot of time to reacquaint myself
with that skill set to be able to make any web site modification.
So keeping that task in-house does not lend itself to nimble and
speedy service here. And sometimes mgmt signs contracts with
vendors first and

consults IT later (if at all).

I just need to know how I need to do my part as responsibly and

professionally as I can.

-- MK