I see your point. It is not specifically written in the PCI-DSS document that a web server has to be configured with the x-frame option but there is a requirement to have an external scan done every quarter. If if that external scanner issues a failing status because the x-frame option is not found and our acquirer can cut us off for having a failing status it is functionally a standard to keep taking credit cards. And they could both argue that this would fall under Requirement 2.2.3 "Implement additional security features for any required services, protocols, or daemons that are considered to be insecure"

________________________________________
From: WEB400 [web400-bounces@xxxxxxxxxxxx] on behalf of Nathan Andelin [nandelin@xxxxxxxxx]
Sent: Wednesday, March 16, 2016 7:49 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] alternative to <iframe>

Nathan here - not Rob. Since the web pages originate on external Windows
servers, forget what I said about GETURI and HTTPAPI. I now understand that
external web pages have embedded iframes pointing to your IBM i Apache
server.

By "PCI scam", I'm referring to "vendors" who make up their own standards
and pass them off as PCI.

If I understand correctly, your "scans" are failing because you're not
using Apache x-frames. Your vendor is suggesting that your web sites are
therefore vulnerable to clickJacking.

Your vendor appears to be "scamming" you in the sense that neither
x-frames, nor iframes, nor clickJacking is covered by PCI standards.

If you are concerned about malicious external sites referencing your site
in their iframes, the best way to handle that is via user authentication /
authorization. I believe you could also white-list certain "origins" in
your applications.

The problem with your vendor's assertions, is that they appear to
indiscriminately be forbidding the use of iframes in external sites.




On Wed, Mar 16, 2016 at 1:51 PM, Mike Cunningham <mike.cunningham@xxxxxxx>
wrote:

Rob, not a scam. We use scanning service that our credit card processors
had us use and that is who is failing us on the external scan requirement
of PCI. Others are reporting the same failure.
http://portal.cavallocomm.com/knowledgebase/34/Implementation-of-PCI-Compliant-Headers.html

The div options sounds like our best option to try with the possible
exception of Sharepoint where we use either the provided web parts or have
to write custom web parts which I don't really want to get into. The only
provided tool to do what we are doing uses iFrames.

I would love to see a code example

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Sent: Wednesday, March 16, 2016 12:52 PM
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] alternative to <iframe>

I agree with Nathan.

Simply get the contents of the page and display in a DIV or any other
suitable control of your choosing.

I do it every day with out a problem. Well, sometimes I have to use
CURL for those sites that attempt to prevent crawling. If you need code to
make your server request to look like it is a browser, just let me know.

Happy Coding,
Rob

On 03/16/2016 09:58 AM, Nathan Andelin wrote:
Mike,

Last I checked, "frame-busting hacks" like x-frames were not part of PCI.
You probably have good grounds for ignoring your latest "PCI scan", in
that regard.

iframes provide useful functionality. clickJacking is a problem with
malicious sites. Does anyone have cause to view your web applications
as being malicious?

However, if you really do want to provide content from multiple sites
without using iframes, the idea of using GETURI (or HTTPAPI) to
retrieve "content" from "foreign" sites and passing it through to your
users seems like the best alternative. It will require some redesign
and rework of any applications that currently use iframes.

--
Your Out-Source IT Department,
Rob Couch
IT Serenity
214 682 7638
Skype: itserenity

--
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.

--
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.


--
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 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.