× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.