|
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-----to
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.SQL uses static SQL statements only (currently), and I'm validating the
Do you know of any RPG/SQL tricks to trap SQL injection? My embedded
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
check and sanitize.
consults IT later (if at all).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 teamget in the way of what's best. I am the only one here that knew the
often
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
professionally as I can.
I just need to know how I need to do my part as responsibly and
-- MK
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.