Multiple Catalogs

[Jeremy Olmstead]

I am not sure if this functionality is available OOTB.  If it is, could
someone let me know, and if it is not, could someone point me in the right
direction on how this may be accomplished?  What I would like to be able to
do is have two catalogs with totally different break downs in categories.
 One would be for internal purposes and the other for e-commerce purposes.
 All products would be in the internal catalog and all items there should
be able to be ordered, but not necessarily from the e-commerce site.  The
e-commerce catalog would be a subset of the internal catalog products and
all items in there would be available for order internally and on
e-commerce.  This is mainly for product breakdown navigation, but also
there are some products we don't want to sell on the Internet.  Thanks for
any help.

Jeremy

[Jose F. Fernandez]

Hi Jeremy,

you can create many catalogs (Application CATALOG MANAGER - Catalogs).
In the new created catalog you can tell in wich stores it may be visible and associate the product categories for that catalog.
I recommend that you create a new product categories tree for the e-commerce site.
That tree must be under a root category with type "Browse Root (One)" and that root category is what you assign to your catalog.

Look at the example catalogs for reference.

Best regards,
Jose F.


----- Mensaje original -----

> De: "Jeremy Olmstead" <[hidden email]>
> Para: [hidden email]
> Enviados: Miércoles, 21 de Marzo 2012 14:34:32
> Asunto: Multiple Catalogs

> I am not sure if this functionality is available OOTB. If it is,
> could
> someone let me know, and if it is not, could someone point me in the
> right
> direction on how this may be accomplished? What I would like to be
> able to
> do is have two catalogs with totally different break downs in
> categories.
> One would be for internal purposes and the other for e-commerce
> purposes.
> All products would be in the internal catalog and all items there
> should
> be able to be ordered, but not necessarily from the e-commerce site.
> The
> e-commerce catalog would be a subset of the internal catalog products
> and
> all items in there would be available for order internally and on
> e-commerce. This is mainly for product breakdown navigation, but also
> there are some products we don't want to sell on the Internet. Thanks
> for
> any help.

> Jeremy

[Jeremy Olmstead]

I have done this, but something is still not right.  How do I set my
internal catalog to not show on the web?  When I do a search or even a
direct link, my internal catalog items still show up on the e-commerce site.

On Wed, Mar 21, 2012 at 8:59 AM, Jose F. Fernandez
<[hidden email]>wrote:

> Hi Jeremy,
>
> you can create many catalogs (Application CATALOG MANAGER - Catalogs).
> In the new created catalog you can tell in wich stores it may be visible
> and associate the product categories for that catalog.
> I recommend that you create a new product categories tree for the
> e-commerce site.
> That tree must be under a root category with type "Browse Root (One)" and
> that root category is what you assign to your catalog.
>
> Look at the example catalogs for reference.
>
> Best regards,
> Jose F.
>
>
> ----- Mensaje original -----
>
> > De: "Jeremy Olmstead" <[hidden email]>
> > Para: [hidden email]
> > Enviados: Miércoles, 21 de Marzo 2012 14:34:32
> > Asunto: Multiple Catalogs
>
> > I am not sure if this functionality is available OOTB. If it is,
> > could
> > someone let me know, and if it is not, could someone point me in the
> > right
> > direction on how this may be accomplished? What I would like to be
> > able to
> > do is have two catalogs with totally different break downs in
> > categories.
> > One would be for internal purposes and the other for e-commerce
> > purposes.
> > All products would be in the internal catalog and all items there
> > should
> > be able to be ordered, but not necessarily from the e-commerce site.
> > The
> > e-commerce catalog would be a subset of the internal catalog products
> > and
> > all items in there would be available for order internally and on
> > e-commerce. This is mainly for product breakdown navigation, but also
> > there are some products we don't want to sell on the Internet. Thanks
> > for
> > any help.
>
> > Jeremy
>

[Jacques Le Roux]

Did you try
https://cwiki.apache.org/confluence/display/OFBENDUSER/Apache+OFBiz+Business+Setup+Guide#ApacheOFBizBusinessSetupGuide-catalogCategoryProductSetup ?

Jacques

Jeremy Olmstead wrote:

> I have done this, but something is still not right.  How do I set my
> internal catalog to not show on the web?  When I do a search or even a
> direct link, my internal catalog items still show up on the e-commerce site.
>
> On Wed, Mar 21, 2012 at 8:59 AM, Jose F. Fernandez
> <[hidden email]>wrote:
>
>> Hi Jeremy,
>>
>> you can create many catalogs (Application CATALOG MANAGER - Catalogs).
>> In the new created catalog you can tell in wich stores it may be visible
>> and associate the product categories for that catalog.
>> I recommend that you create a new product categories tree for the
>> e-commerce site.
>> That tree must be under a root category with type "Browse Root (One)" and
>> that root category is what you assign to your catalog.
>>
>> Look at the example catalogs for reference.
>>
>> Best regards,
>> Jose F.
>>
>>
>> ----- Mensaje original -----
>>
>>> De: "Jeremy Olmstead" <[hidden email]>
>>> Para: [hidden email]
>>> Enviados: Miércoles, 21 de Marzo 2012 14:34:32
>>> Asunto: Multiple Catalogs
>>
>>> I am not sure if this functionality is available OOTB. If it is,
>>> could
>>> someone let me know, and if it is not, could someone point me in the
>>> right
>>> direction on how this may be accomplished? What I would like to be
>>> able to
>>> do is have two catalogs with totally different break downs in
>>> categories.
>>> One would be for internal purposes and the other for e-commerce
>>> purposes.
>>> All products would be in the internal catalog and all items there
>>> should
>>> be able to be ordered, but not necessarily from the e-commerce site.
>>> The
>>> e-commerce catalog would be a subset of the internal catalog products
>>> and
>>> all items in there would be available for order internally and on
>>> e-commerce. This is mainly for product breakdown navigation, but also
>>> there are some products we don't want to sell on the Internet. Thanks
>>> for
>>> any help.
>>
>>> Jeremy

[Vicky Park]

Hello folks,


I realized that printing some information on log files could violate PCI
CSS (Payment Card Industry Data Security Standard) depends on how they
configure the system, and how to use the log file. If I understood
correctly, we're printing card holder's information including credit
card number, expiration and CVV num in plain text on log file.

If we don't print out on the log at all on the live site, that would
solve the problem. But if there is a person who wasn't aware of that
fact,  he might accidentally violate the PCI DSS compliance. For
example, let's say there is a person who keeps the log to be printed on
the live site. And for some reason, he downloaded log file to his local
computer and kept unsafe location, or passed to someone else to let them
take a look that log file for asking help. Then I believe he is
violating the PCI CSS compliance accidentally.


Code involved 1:
[PayflowPro.java:166]
if (Debug.verboseOn()) Debug.logVerbose("Sending to Verisign: " +
params.toString(), module);


Logs which is being printed:
[Datetime] (TP-Processor70) [         PayflowPro.java:166:INFO ] Sending
to Verisign: PARTNER=verisign&VENDOR=[Company
]&USER=[UserID]&PWD=[Password]&COMMENT1=[Order ID]&PONUM=[PO Order Id]
&CUSTCODE=[Customer's code]&TRXTYPE=[]&TENDER=[]&CVV2=*[CVV
number*]&AMT=[Amount]&ACCT=*[16 digit credit card number in plain
text]*&FIRSTNAME=[Cardholder's firstname]&LASTNAME=[Card holder's last
name]&COMMENT2=[]&EXPDATE=*[expiration date]*&STREET=[Card holder's
address&ZIP=[card holder's zip code]


Code involved 2:
[RequestHandler.java:719]
if (Debug.infoOn()) Debug.logInfo("Sending redirect to: [" + url + "],
sessionId=" + UtilHttp.getSessionId(req), module);

=> I realized that credit card information is being printed from
different file as well (RequestHandler.java:719). I need to check what
service triggers RequestHandler.java:719 and passes credit card
information within url variable. But at least I noticed sometimes that
line in the log file contains credit card information in plain text as well.


PCI DSS involved:
7. Restrict access to cardholder data by business need-to-know
9. Restrict physical access to cardholder data
[Reference]http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard



So, here is my questions & recommendation:

1. As we (at least I) want to keep log for in case, I think it's better
to not to print out credit card information to the log file. What do you
think? Do you think deleting that line is the best option?
2.  If you guys think it's better to print out at least some information
to log file for some purpose, I believe it's better to print out in
encrypted format rather than in plain text. Otherwise we can print out
last 4 digit or first 4 digit, not entire number.
3. Do you know what triggers RequestHander to print out credit card
information?
4. Is there any other file you can think of which likely print out
credit card information to log file?


Hope it would be helpful for security improvement for myself and someone
else who may use ofbiz on the live site.


Thanks you for reading.

[Pierre Smits]

Please check if a JIRA exist re this issue. If not create one, please.

Regards,

Pierre

Sent from my iPhone

On 21 mrt. 2012, at 17:25, Vicky Park <[hidden email]> wrote:

> Hello folks,
>
>
> I realized that printing some information on log files could violate PCI CSS (Payment Card Industry Data Security Standard) depends on how they configure the system, and how to use the log file. If I understood correctly, we're printing card holder's information including credit card number, expiration and CVV num in plain text on log file.
>
> If we don't print out on the log at all on the live site, that would solve the problem. But if there is a person who wasn't aware of that fact,  he might accidentally violate the PCI DSS compliance. For example, let's say there is a person who keeps the log to be printed on the live site. And for some reason, he downloaded log file to his local computer and kept unsafe location, or passed to someone else to let them take a look that log file for asking help. Then I believe he is violating the PCI CSS compliance accidentally.
>
>
> Code involved 1:
> [PayflowPro.java:166]
> if (Debug.verboseOn()) Debug.logVerbose("Sending to Verisign: " + params.toString(), module);
>
>
> Logs which is being printed:
> [Datetime] (TP-Processor70) [         PayflowPro.java:166:INFO ] Sending to Verisign: PARTNER=verisign&VENDOR=[Company ]&USER=[UserID]&PWD=[Password]&COMMENT1=[Order ID]&PONUM=[PO Order Id] &CUSTCODE=[Customer's code]&TRXTYPE=[]&TENDER=[]&CVV2=*[CVV number*]&AMT=[Amount]&ACCT=*[16 digit credit card number in plain text]*&FIRSTNAME=[Cardholder's firstname]&LASTNAME=[Card holder's last name]&COMMENT2=[]&EXPDATE=*[expiration date]*&STREET=[Card holder's address&ZIP=[card holder's zip code]
>
>
> Code involved 2:
> [RequestHandler.java:719]
> if (Debug.infoOn()) Debug.logInfo("Sending redirect to: [" + url + "], sessionId=" + UtilHttp.getSessionId(req), module);
>
> => I realized that credit card information is being printed from different file as well (RequestHandler.java:719). I need to check what service triggers RequestHandler.java:719 and passes credit card information within url variable. But at least I noticed sometimes that line in the log file contains credit card information in plain text as well.
>
>
> PCI DSS involved:
> 7. Restrict access to cardholder data by business need-to-know
> 9. Restrict physical access to cardholder data
> [Reference]http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard
>
>
>
> So, here is my questions & recommendation:
>
> 1. As we (at least I) want to keep log for in case, I think it's better to not to print out credit card information to the log file. What do you think? Do you think deleting that line is the best option?
> 2.  If you guys think it's better to print out at least some information to log file for some purpose, I believe it's better to print out in encrypted format rather than in plain text. Otherwise we can print out last 4 digit or first 4 digit, not entire number.
> 3. Do you know what triggers RequestHander to print out credit card information?
> 4. Is there any other file you can think of which likely print out credit card information to log file?
>
>
> Hope it would be helpful for security improvement for myself and someone else who may use ofbiz on the live site.
>
>
> Thanks you for reading.
>

[Jacques Le Roux]

From: "Vicky Park" <[hidden email]>

> Hello folks,
>
>
> I realized that printing some information on log files could violate PCI
> CSS (Payment Card Industry Data Security Standard) depends on how they
> configure the system, and how to use the log file. If I understood
> correctly, we're printing card holder's information including credit
> card number, expiration and CVV num in plain text on log file.
>
> If we don't print out on the log at all on the live site, that would
> solve the problem. But if there is a person who wasn't aware of that
> fact,  he might accidentally violate the PCI DSS compliance. For
> example, let's say there is a person who keeps the log to be printed on
> the live site. And for some reason, he downloaded log file to his local
> computer and kept unsafe location, or passed to someone else to let them
> take a look that log file for asking help. Then I believe he is
> violating the PCI CSS compliance accidentally.
>
>
> Code involved 1:
> [PayflowPro.java:166]
> if (Debug.verboseOn()) Debug.logVerbose("Sending to Verisign: " +
> params.toString(), module);
>
>
> Logs which is being printed:
> [Datetime] (TP-Processor70) [         PayflowPro.java:166:INFO ] Sending
> to Verisign: PARTNER=verisign&VENDOR=[Company
> ]&USER=[UserID]&PWD=[Password]&COMMENT1=[Order ID]&PONUM=[PO Order Id]
> &CUSTCODE=[Customer's code]&TRXTYPE=[]&TENDER=[]&CVV2=*[CVV
> number*]&AMT=[Amount]&ACCT=*[16 digit credit card number in plain
> text]*&FIRSTNAME=[Cardholder's firstname]&LASTNAME=[Card holder's last
> name]&COMMENT2=[]&EXPDATE=*[expiration date]*&STREET=[Card holder's
> address&ZIP=[card holder's zip code]
>
>
> Code involved 2:
> [RequestHandler.java:719]
> if (Debug.infoOn()) Debug.logInfo("Sending redirect to: [" + url + "],
> sessionId=" + UtilHttp.getSessionId(req), module);
>
> => I realized that credit card information is being printed from
> different file as well (RequestHandler.java:719). I need to check what
> service triggers RequestHandler.java:719 and passes credit card
> information within url variable. But at least I noticed sometimes that
> line in the log file contains credit card information in plain text as well.
>
>
> PCI DSS involved:
> 7. Restrict access to cardholder data by business need-to-know
> 9. Restrict physical access to cardholder data
> [Reference]http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard
>
>
>
> So, here is my questions & recommendation:
>
> 1. As we (at least I) want to keep log for in case, I think it's better
> to not to print out credit card information to the log file. What do you
> think? Do you think deleting that line is the best option?

It's very unlikely that anybody would run a production server with log set at verbose level at any moment for all classes/packages.
But we could easily comment out this line indeed (not deleting it)

> 2.  If you guys think it's better to print out at least some information
> to log file for some purpose, I believe it's better to print out in
> encrypted format rather than in plain text. Otherwise we can print out
> last 4 digit or first 4 digit, not entire number.

Not needed if commentout, then people would be really aware that they are sending it to log

> 3. Do you know what triggers RequestHander to print out credit card
> information?

I expect commenting line in PayflowPro.java would be enough

> 4. Is there any other file you can think of which likely print out
> credit card information to log file?

I don't think so. PayflowPro is not used OOTB in OFBiz IIRW

Jacques

>
> Hope it would be helpful for security improvement for myself and someone
> else who may use ofbiz on the live site.
>
>
> Thanks you for reading.
>
>

[Jeremy Olmstead]

Well, sort of.  I used the information to initially bulk load data into
Catalog/Category/Product, etc.  It was later that I decided I needed a
different break down on the e-commerce site and that not all products
should be on the web.  I deleted the initial catalog from the web store and
put a new manually created web specific catalog up as the catalog for the
web store.  I actually thought this is all I should have needed to do, but
it didn't work, I still get all of the initial data.  Then I changed the
internal catalog type to View Allow instead of Browse Root and even changed
every category type to Internal instead of catalog.  At least the correct
categories now show up on the left side navigation, but even there, when I
drill down to a specific product and click the product detail link from the
drill down it still shows me the product as if it is from the internal
catalog!  I stopped the server and restarted MySql thinking it was some
kind of caching issue, but I still have the same problem.

Jeremy

On Wed, Mar 21, 2012 at 9:32 AM, Jacques Le Roux <
[hidden email]> wrote:

> Did you try https://cwiki.apache.org/**confluence/display/OFBENDUSER/**
> Apache+OFBiz+Business+Setup+**Guide#**ApacheOFBizBusinessSetupGuide-**
> catalogCategoryProductSetup<https://cwiki.apache.org/confluence/display/OFBENDUSER/Apache+OFBiz+Business+Setup+Guide#ApacheOFBizBusinessSetupGuide-catalogCategoryProductSetup>?
>
> Jacques
>
>
> Jeremy Olmstead wrote:
>
>> I have done this, but something is still not right.  How do I set my
>> internal catalog to not show on the web?  When I do a search or even a
>> direct link, my internal catalog items still show up on the e-commerce
>> site.
>>
>> On Wed, Mar 21, 2012 at 8:59 AM, Jose F. Fernandez
>> <[hidden email]>**wrote:
>>
>>  Hi Jeremy,
>>>
>>> you can create many catalogs (Application CATALOG MANAGER - Catalogs).
>>> In the new created catalog you can tell in wich stores it may be visible
>>> and associate the product categories for that catalog.
>>> I recommend that you create a new product categories tree for the
>>> e-commerce site.
>>> That tree must be under a root category with type "Browse Root (One)" and
>>> that root category is what you assign to your catalog.
>>>
>>> Look at the example catalogs for reference.
>>>
>>> Best regards,
>>> Jose F.
>>>
>>>
>>> ----- Mensaje original -----
>>>
>>>  De: "Jeremy Olmstead" <[hidden email]>
>>>> Para: [hidden email]
>>>> Enviados: Miércoles, 21 de Marzo 2012 14:34:32
>>>> Asunto: Multiple Catalogs
>>>>
>>>
>>>  I am not sure if this functionality is available OOTB. If it is,
>>>> could
>>>> someone let me know, and if it is not, could someone point me in the
>>>> right
>>>> direction on how this may be accomplished? What I would like to be
>>>> able to
>>>> do is have two catalogs with totally different break downs in
>>>> categories.
>>>> One would be for internal purposes and the other for e-commerce
>>>> purposes.
>>>> All products would be in the internal catalog and all items there
>>>> should
>>>> be able to be ordered, but not necessarily from the e-commerce site.
>>>> The
>>>> e-commerce catalog would be a subset of the internal catalog products
>>>> and
>>>> all items in there would be available for order internally and on
>>>> e-commerce. This is mainly for product breakdown navigation, but also
>>>> there are some products we don't want to sell on the Internet. Thanks
>>>> for
>>>> any help.
>>>>
>>>
>>>  Jeremy
>>>>
>>>

[Paul Piper]

I also agree that this is probably a security issue and could mean that you
are not getting the proper validation by credit card companies. You need to
be accredited by credit card companies with PCI CSS to even be allowed to
support creditcard transaction directly (unless you use an external iPayment
service for this) and there you cannot store this sort of data in the logs.
Only xxxx-ed out credit card information should be used.

---
Paul Piper
Geschäftsführer
 
 
Web: http://www.ilscipio.com
Tel: [phone]
Mobil: ([phone]
Fax: [phone]
eMail: [hidden email]

 
ilscipio GmbH
Am Drosselschlag 7
D-35452 Heuchelheim
Germany

-----Ursprüngliche Nachricht-----
Von: Jacques Le Roux [mailto:[hidden email]]
Gesendet: Mittwoch, 21. März 2012 19:47
An: [hidden email]
Betreff: Re: [Security Concern] Printing out credit card information on the
log file?

From: "Vicky Park" <[hidden email]>
> Hello folks,
>
>
> I realized that printing some information on log files could violate
> PCI CSS (Payment Card Industry Data Security Standard) depends on how
> they configure the system, and how to use the log file. If I
> understood correctly, we're printing card holder's information
> including credit card number, expiration and CVV num in plain text on log
file.

>
> If we don't print out on the log at all on the live site, that would
> solve the problem. But if there is a person who wasn't aware of that
> fact,  he might accidentally violate the PCI DSS compliance. For
> example, let's say there is a person who keeps the log to be printed
> on the live site. And for some reason, he downloaded log file to his
> local computer and kept unsafe location, or passed to someone else to
> let them take a look that log file for asking help. Then I believe he
> is violating the PCI CSS compliance accidentally.
>
>
> Code involved 1:
> [PayflowPro.java:166]
> if (Debug.verboseOn()) Debug.logVerbose("Sending to Verisign: " +
> params.toString(), module);
>
>
> Logs which is being printed:
> [Datetime] (TP-Processor70) [         PayflowPro.java:166:INFO ] Sending
> to Verisign: PARTNER=verisign&VENDOR=[Company
> ]&USER=[UserID]&PWD=[Password]&COMMENT1=[Order ID]&PONUM=[PO Order Id]
> &CUSTCODE=[Customer's code]&TRXTYPE=[]&TENDER=[]&CVV2=*[CVV
> number*]&AMT=[Amount]&ACCT=*[16 digit credit card number in plain
> text]*&FIRSTNAME=[Cardholder's firstname]&LASTNAME=[Card holder's last
> name]&COMMENT2=[]&EXPDATE=*[expiration date]*&STREET=[Card holder's
> address&ZIP=[card holder's zip code]
>
>
> Code involved 2:
> [RequestHandler.java:719]
> if (Debug.infoOn()) Debug.logInfo("Sending redirect to: [" + url + "],
> sessionId=" + UtilHttp.getSessionId(req), module);
>
> => I realized that credit card information is being printed from
> different file as well (RequestHandler.java:719). I need to check what
> service triggers RequestHandler.java:719 and passes credit card
> information within url variable. But at least I noticed sometimes that
> line in the log file contains credit card information in plain text as

well.

>
>
> PCI DSS involved:
> 7. Restrict access to cardholder data by business need-to-know 9.
> Restrict physical access to cardholder data
> [Reference]http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec
> urity_Standard
>
>
>
> So, here is my questions & recommendation:
>
> 1. As we (at least I) want to keep log for in case, I think it's
> better to not to print out credit card information to the log file.
> What do you think? Do you think deleting that line is the best option?

It's very unlikely that anybody would run a production server with log set
at verbose level at any moment for all classes/packages.
But we could easily comment out this line indeed (not deleting it)

> 2.  If you guys think it's better to print out at least some
> information to log file for some purpose, I believe it's better to
> print out in encrypted format rather than in plain text. Otherwise we
> can print out last 4 digit or first 4 digit, not entire number.

Not needed if commentout, then people would be really aware that they are
sending it to log

> 3. Do you know what triggers RequestHander to print out credit card
> information?

I expect commenting line in PayflowPro.java would be enough

> 4. Is there any other file you can think of which likely print out
> credit card information to log file?

I don't think so. PayflowPro is not used OOTB in OFBiz IIRW

Jacques

>
> Hope it would be helpful for security improvement for myself and
> someone else who may use ofbiz on the live site.
>
>
> Thanks you for reading.
>
>

[Jacques Le Roux]

Hi Paul,

As suggested in my answer to Vicky, I have commented out the line  [PayflowPro.java:166]
in trunk and ALL releases (including R4.0)

Please Vicky could you please confirm that this change is enough for the other points you raised?

Trunk test is enough because all the automatic backports worked well, which is not surprising because this is really an old
adaptation to an external payment provider.

Jacques

Paul Piper wrote:

> I also agree that this is probably a security issue and could mean that you
> are not getting the proper validation by credit card companies. You need to
> be accredited by credit card companies with PCI CSS to even be allowed to
> support creditcard transaction directly (unless you use an external iPayment
> service for this) and there you cannot store this sort of data in the logs.
> Only xxxx-ed out credit card information should be used.
>
> ---
> Paul Piper
> Geschäftsführer
>
>
> Web: http://www.ilscipio.com
> Tel: [phone]
> Mobil: ([phone]
> Fax: [phone]
> eMail: [hidden email]
>
>
> ilscipio GmbH
> Am Drosselschlag 7
> D-35452 Heuchelheim
> Germany
>
> -----Ursprüngliche Nachricht-----
> Von: Jacques Le Roux [mailto:[hidden email]]
> Gesendet: Mittwoch, 21. März 2012 19:47
> An: [hidden email]
> Betreff: Re: [Security Concern] Printing out credit card information on the
> log file?
>
> From: "Vicky Park" <[hidden email]>
>> Hello folks,
>>
>>
>> I realized that printing some information on log files could violate
>> PCI CSS (Payment Card Industry Data Security Standard) depends on how
>> they configure the system, and how to use the log file. If I
>> understood correctly, we're printing card holder's information
>> including credit card number, expiration and CVV num in plain text on log file.
>>
>> If we don't print out on the log at all on the live site, that would
>> solve the problem. But if there is a person who wasn't aware of that
>> fact,  he might accidentally violate the PCI DSS compliance. For
>> example, let's say there is a person who keeps the log to be printed
>> on the live site. And for some reason, he downloaded log file to his
>> local computer and kept unsafe location, or passed to someone else to
>> let them take a look that log file for asking help. Then I believe he
>> is violating the PCI CSS compliance accidentally.
>>
>>
>> Code involved 1:
>> [PayflowPro.java:166]
>> if (Debug.verboseOn()) Debug.logVerbose("Sending to Verisign: " +
>> params.toString(), module);
>>
>>
>> Logs which is being printed:
>> [Datetime] (TP-Processor70) [         PayflowPro.java:166:INFO ] Sending
>> to Verisign: PARTNER=verisign&VENDOR=[Company
>> ]&USER=[UserID]&PWD=[Password]&COMMENT1=[Order ID]&PONUM=[PO Order Id]
>> &CUSTCODE=[Customer's code]&TRXTYPE=[]&TENDER=[]&CVV2=*[CVV
>> number*]&AMT=[Amount]&ACCT=*[16 digit credit card number in plain
>> text]*&FIRSTNAME=[Cardholder's firstname]&LASTNAME=[Card holder's last
>> name]&COMMENT2=[]&EXPDATE=*[expiration date]*&STREET=[Card holder's
>> address&ZIP=[card holder's zip code]
>>
>>
>> Code involved 2:
>> [RequestHandler.java:719]
>> if (Debug.infoOn()) Debug.logInfo("Sending redirect to: [" + url + "],
>> sessionId=" + UtilHttp.getSessionId(req), module);
>>
>> => I realized that credit card information is being printed from
>> different file as well (RequestHandler.java:719). I need to check what
>> service triggers RequestHandler.java:719 and passes credit card
>> information within url variable. But at least I noticed sometimes that
>> line in the log file contains credit card information in plain text as well.
>>
>>
>> PCI DSS involved:
>> 7. Restrict access to cardholder data by business need-to-know 9.
>> Restrict physical access to cardholder data
>> [Reference]http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec
>> urity_Standard
>>
>>
>>
>> So, here is my questions & recommendation:
>>
>> 1. As we (at least I) want to keep log for in case, I think it's
>> better to not to print out credit card information to the log file.
>> What do you think? Do you think deleting that line is the best option?
>
> It's very unlikely that anybody would run a production server with log set
> at verbose level at any moment for all classes/packages.
> But we could easily comment out this line indeed (not deleting it)
>
>> 2.  If you guys think it's better to print out at least some
>> information to log file for some purpose, I believe it's better to
>> print out in encrypted format rather than in plain text. Otherwise we
>> can print out last 4 digit or first 4 digit, not entire number.
>
> Not needed if commentout, then people would be really aware that they are
> sending it to log
>
>> 3. Do you know what triggers RequestHander to print out credit card
>> information?
>
> I expect commenting line in PayflowPro.java would be enough
>
>> 4. Is there any other file you can think of which likely print out
>> credit card information to log file?
>
> I don't think so. PayflowPro is not used OOTB in OFBiz IIRW
>
> Jacques
>
>>
>> Hope it would be helpful for security improvement for myself and
>> someone else who may use ofbiz on the live site.
>>
>>
>> Thanks you for reading.

[Jacques Le Roux]

Mmm... indeed, IIRW something like that has been reported lately. I don't remember if we created a Jira. I will have a look and will
create one if needed

Jacques

Jeremy Olmstead wrote:

> Well, sort of.  I used the information to initially bulk load data into
> Catalog/Category/Product, etc.  It was later that I decided I needed a
> different break down on the e-commerce site and that not all products
> should be on the web.  I deleted the initial catalog from the web store and
> put a new manually created web specific catalog up as the catalog for the
> web store.  I actually thought this is all I should have needed to do, but
> it didn't work, I still get all of the initial data.  Then I changed the
> internal catalog type to View Allow instead of Browse Root and even changed
> every category type to Internal instead of catalog.  At least the correct
> categories now show up on the left side navigation, but even there, when I
> drill down to a specific product and click the product detail link from the
> drill down it still shows me the product as if it is from the internal
> catalog!  I stopped the server and restarted MySql thinking it was some
> kind of caching issue, but I still have the same problem.
>
> Jeremy
>
> On Wed, Mar 21, 2012 at 9:32 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Did you try https://cwiki.apache.org/**confluence/display/OFBENDUSER/**
>> Apache+OFBiz+Business+Setup+**Guide#**ApacheOFBizBusinessSetupGuide-**
>> catalogCategoryProductSetup<https://cwiki.apache.org/confluence/display/OFBENDUSER/Apache+OFBiz+Business+Setup+Guide#ApacheOFBizBusinessSetupGuide-catalogCategoryProductSetup>?
>>
>> Jacques
>>
>>
>> Jeremy Olmstead wrote:
>>
>>> I have done this, but something is still not right.  How do I set my
>>> internal catalog to not show on the web?  When I do a search or even a
>>> direct link, my internal catalog items still show up on the e-commerce
>>> site.
>>>
>>> On Wed, Mar 21, 2012 at 8:59 AM, Jose F. Fernandez
>>> <[hidden email]>**wrote:
>>>
>>>  Hi Jeremy,
>>>>
>>>> you can create many catalogs (Application CATALOG MANAGER - Catalogs).
>>>> In the new created catalog you can tell in wich stores it may be visible
>>>> and associate the product categories for that catalog.
>>>> I recommend that you create a new product categories tree for the
>>>> e-commerce site.
>>>> That tree must be under a root category with type "Browse Root (One)" and
>>>> that root category is what you assign to your catalog.
>>>>
>>>> Look at the example catalogs for reference.
>>>>
>>>> Best regards,
>>>> Jose F.
>>>>
>>>>
>>>> ----- Mensaje original -----
>>>>
>>>>  De: "Jeremy Olmstead" <[hidden email]>
>>>>> Para: [hidden email]
>>>>> Enviados: Miércoles, 21 de Marzo 2012 14:34:32
>>>>> Asunto: Multiple Catalogs
>>>>>
>>>>
>>>>  I am not sure if this functionality is available OOTB. If it is,
>>>>> could
>>>>> someone let me know, and if it is not, could someone point me in the
>>>>> right
>>>>> direction on how this may be accomplished? What I would like to be
>>>>> able to
>>>>> do is have two catalogs with totally different break downs in
>>>>> categories.
>>>>> One would be for internal purposes and the other for e-commerce
>>>>> purposes.
>>>>> All products would be in the internal catalog and all items there
>>>>> should
>>>>> be able to be ordered, but not necessarily from the e-commerce site.
>>>>> The
>>>>> e-commerce catalog would be a subset of the internal catalog products
>>>>> and
>>>>> all items in there would be available for order internally and on
>>>>> e-commerce. This is mainly for product breakdown navigation, but also
>>>>> there are some products we don't want to sell on the Internet. Thanks
>>>>> for
>>>>> any help.
>>>>>
>>>>
>>>>  Jeremy

[Jacques Le Roux-3]

Yes that was here http://markmail.org/message/7jju5vtwooybywml
Time to create a Jira, could you do it for me Jeremy?
You can use the details you gave below

Thanks

Jacques


From: "Jacques Le Roux" <[hidden email]>

> Mmm... indeed, IIRW something like that has been reported lately. I don't remember if we created a Jira. I will have a look and
> will create one if needed
>
> Jacques
>
> Jeremy Olmstead wrote:
>> Well, sort of.  I used the information to initially bulk load data into
>> Catalog/Category/Product, etc.  It was later that I decided I needed a
>> different break down on the e-commerce site and that not all products
>> should be on the web.  I deleted the initial catalog from the web store and
>> put a new manually created web specific catalog up as the catalog for the
>> web store.  I actually thought this is all I should have needed to do, but
>> it didn't work, I still get all of the initial data.  Then I changed the
>> internal catalog type to View Allow instead of Browse Root and even changed
>> every category type to Internal instead of catalog.  At least the correct
>> categories now show up on the left side navigation, but even there, when I
>> drill down to a specific product and click the product detail link from the
>> drill down it still shows me the product as if it is from the internal
>> catalog!  I stopped the server and restarted MySql thinking it was some
>> kind of caching issue, but I still have the same problem.
>>
>> Jeremy
>>
>> On Wed, Mar 21, 2012 at 9:32 AM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>> Did you try https://cwiki.apache.org/**confluence/display/OFBENDUSER/**
>>> Apache+OFBiz+Business+Setup+**Guide#**ApacheOFBizBusinessSetupGuide-**
>>> catalogCategoryProductSetup<https://cwiki.apache.org/confluence/display/OFBENDUSER/Apache+OFBiz+Business+Setup+Guide#ApacheOFBizBusinessSetupGuide-catalogCategoryProductSetup>?
>>>
>>> Jacques
>>>
>>>
>>> Jeremy Olmstead wrote:
>>>
>>>> I have done this, but something is still not right.  How do I set my
>>>> internal catalog to not show on the web?  When I do a search or even a
>>>> direct link, my internal catalog items still show up on the e-commerce
>>>> site.
>>>>
>>>> On Wed, Mar 21, 2012 at 8:59 AM, Jose F. Fernandez
>>>> <[hidden email]>**wrote:
>>>>
>>>>  Hi Jeremy,
>>>>>
>>>>> you can create many catalogs (Application CATALOG MANAGER - Catalogs).
>>>>> In the new created catalog you can tell in wich stores it may be visible
>>>>> and associate the product categories for that catalog.
>>>>> I recommend that you create a new product categories tree for the
>>>>> e-commerce site.
>>>>> That tree must be under a root category with type "Browse Root (One)" and
>>>>> that root category is what you assign to your catalog.
>>>>>
>>>>> Look at the example catalogs for reference.
>>>>>
>>>>> Best regards,
>>>>> Jose F.
>>>>>
>>>>>
>>>>> ----- Mensaje original -----
>>>>>
>>>>>  De: "Jeremy Olmstead" <[hidden email]>
>>>>>> Para: [hidden email]
>>>>>> Enviados: Miércoles, 21 de Marzo 2012 14:34:32
>>>>>> Asunto: Multiple Catalogs
>>>>>>
>>>>>
>>>>>  I am not sure if this functionality is available OOTB. If it is,
>>>>>> could
>>>>>> someone let me know, and if it is not, could someone point me in the
>>>>>> right
>>>>>> direction on how this may be accomplished? What I would like to be
>>>>>> able to
>>>>>> do is have two catalogs with totally different break downs in
>>>>>> categories.
>>>>>> One would be for internal purposes and the other for e-commerce
>>>>>> purposes.
>>>>>> All products would be in the internal catalog and all items there
>>>>>> should
>>>>>> be able to be ordered, but not necessarily from the e-commerce site.
>>>>>> The
>>>>>> e-commerce catalog would be a subset of the internal catalog products
>>>>>> and
>>>>>> all items in there would be available for order internally and on
>>>>>> e-commerce. This is mainly for product breakdown navigation, but also
>>>>>> there are some products we don't want to sell on the Internet. Thanks
>>>>>> for
>>>>>> any help.
>>>>>>
>>>>>
>>>>>  Jeremy

[Paul Foxworthy]

Hi all,

It's important that we don't log complete credit cards, so Jacques's
fix is definitely an improvement.

Might there be a need to log masked credit card numbers sometimes?
Perhaps only at the verbose logging level? That ought to be enough to
identify a specific transaction without the security risks of a
complete credit card number.

Jira OFBIZ-1687 introduced a method to mask all but the checksum for a
credit card number, see the method formatPrintableCreditCard in
framework/base/src/org/ofbiz/base/util/UtilFormatOut.java .

Unfortunately fisheye is broken at present, but once it's back the
fisheye URL is https://fisheye6.atlassian.com/browse/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/UtilFormatOut.java?hb=true

I would prefer to see the issuer (i.e. the first six digits) as well
as the checksum (the last four digits). There's example code to do
that at http://adamcaudill.com/2011/10/20/masking-credit-cards-for-pci/

The CVV number should not be stored or logged at all.

What do people think?

Cheers

Paul Foxworthy

Jacques Le Rous wrote:
Hi Paul,

As suggested in my answer to Vicky, I have commented out the line
[PayflowPro.java:166]
in trunk and ALL releases (including R4.0)

Please Vicky could you please confirm that this change is enough for
the other points you raised?

Trunk test is enough because all the automatic backports worked well,
which is not surprising because this is really an old
adaptation to an external payment provider.

Jacques

Paul Piper wrote:

> I also agree that this is probably a security issue and could mean that you
> are not getting the proper validation by credit card companies. You need to
> be accredited by credit card companies with PCI CSS to even be allowed to
> support creditcard transaction directly (unless you use an external iPayment
> service for this) and there you cannot store this sort of data in the logs.
> Only xxxx-ed out credit card information should be used.
>
> ---
> Paul Piper
> Geschäftsführer
>
>
> Web: http://www.ilscipio.com
> Tel: [phone]
> Mobil: ([phone]
> Fax: [phone]
> eMail: <email>pp@</email>
>
>
> ilscipio GmbH
> Am Drosselschlag 7
> D-35452 Heuchelheim
> Germany
>
> -----Ursprüngliche Nachricht-----
> Von: Jacques Le Roux [mailto:<email>jacques.le.roux@</email>]
> Gesendet: Mittwoch, 21. März 2012 19:47
> An: <email>user@.apache</email>
> Betreff: Re: [Security Concern] Printing out credit card information on the
> log file?
>
> From: "Vicky Park" &lt;<email>vicky@</email>&gt;
>> Hello folks,
>>
>>
>> I realized that printing some information on log files could violate
>> PCI CSS (Payment Card Industry Data Security Standard) depends on how
>> they configure the system, and how to use the log file. If I
>> understood correctly, we're printing card holder's information
>> including credit card number, expiration and CVV num in plain text on log file.
>>
>> If we don't print out on the log at all on the live site, that would
>> solve the problem. But if there is a person who wasn't aware of that
>> fact,  he might accidentally violate the PCI DSS compliance. For
>> example, let's say there is a person who keeps the log to be printed
>> on the live site. And for some reason, he downloaded log file to his
>> local computer and kept unsafe location, or passed to someone else to
>> let them take a look that log file for asking help. Then I believe he
>> is violating the PCI CSS compliance accidentally.
>>
>>
>> Code involved 1:
>> [PayflowPro.java:166]
>> if (Debug.verboseOn()) Debug.logVerbose("Sending to Verisign: " +
>> params.toString(), module);
>>
>>
>> Logs which is being printed:
>> [Datetime] (TP-Processor70) [         PayflowPro.java:166:INFO ] Sending
>> to Verisign: PARTNER=verisign&VENDOR=[Company
>> ]&USER=[UserID]&PWD=[Password]&COMMENT1=[Order ID]&PONUM=[PO Order Id]
>> &CUSTCODE=[Customer's code]&TRXTYPE=[]&TENDER=[]&CVV2=*[CVV
>> number*]&AMT=[Amount]&ACCT=*[16 digit credit card number in plain
>> text]*&FIRSTNAME=[Cardholder's firstname]&LASTNAME=[Card holder's last
>> name]&COMMENT2=[]&EXPDATE=*[expiration date]*&STREET=[Card holder's
>> address&ZIP=[card holder's zip code]
>>
>>
>> Code involved 2:
>> [RequestHandler.java:719]
>> if (Debug.infoOn()) Debug.logInfo("Sending redirect to: [" + url + "],
>> sessionId=" + UtilHttp.getSessionId(req), module);
>>
>> => I realized that credit card information is being printed from
>> different file as well (RequestHandler.java:719). I need to check what
>> service triggers RequestHandler.java:719 and passes credit card
>> information within url variable. But at least I noticed sometimes that
>> line in the log file contains credit card information in plain text as well.
>>
>>
>> PCI DSS involved:
>> 7. Restrict access to cardholder data by business need-to-know 9.
>> Restrict physical access to cardholder data
>> [Reference]http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec
>> urity_Standard
>>
>>
>>
>> So, here is my questions & recommendation:
>>
>> 1. As we (at least I) want to keep log for in case, I think it's
>> better to not to print out credit card information to the log file.
>> What do you think? Do you think deleting that line is the best option?
>
> It's very unlikely that anybody would run a production server with log set
> at verbose level at any moment for all classes/packages.
> But we could easily comment out this line indeed (not deleting it)
>
>> 2.  If you guys think it's better to print out at least some
>> information to log file for some purpose, I believe it's better to
>> print out in encrypted format rather than in plain text. Otherwise we
>> can print out last 4 digit or first 4 digit, not entire number.
>
> Not needed if commentout, then people would be really aware that they are
> sending it to log
>
>> 3. Do you know what triggers RequestHander to print out credit card
>> information?
>
> I expect commenting line in PayflowPro.java would be enough
>
>> 4. Is there any other file you can think of which likely print out
>> credit card information to log file?
>
> I don't think so. PayflowPro is not used OOTB in OFBiz IIRW
>
> Jacques
>
>>
>> Hope it would be helpful for security improvement for myself and
>> someone else who may use ofbiz on the live site.
>>
>>
>> Thanks you for reading.

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[Vicky Park]

Good morning guys,

Thanks for the commit. I believe that would be helpful for everybody.

Sorry for late reply. I was working on that issue by myself as well, And
there is one more comment I want to make to the Opentaps user. I do know
it's ofbiz forum, but if you're using Opentaps, then there is one more
thing you may want to check - I know there is similarity b/w two of the
applications, and some of the Opentaps user use ofbiz forum as well.
First part is what Paul commented out - Should be good. And second part
is Redirect part which I mentioned earlier.

I compared and tested ofbiz & opentaps both, and realized there was a
difference b/w two applications in the usage of redirect. After I apply
Paul's commit, I noticed Ofbiz doesn't print out credit card information
anymore, but Opentaps still does.

Here is what it happens. Opentaps use Redirect to handle the payment in
one service(createCreditCard). And the variable is passed to the
redirect handler, and redirect service print out all the variables
received. "Printing out variables received" is not a problem itself. But
combination with "Passing credit card info" could be the problem. And it
turns out printing out credit card information on the log file in plain
text again.


Related code:

[*OFBIZ*:  controller.xml file on the ordermgr section]
<request-map uri="createCreditCard">
<security https="true" auth="true"/>
<event type="simple"
path="component://accounting/script/org/ofbiz/accounting/payment/PaymentMethodEvents.xml"
invoke="createCreditCard"/>
<response name="success" type="*view*" value="editcreditcard"/>
<response name="address" type="*view*" value="editcontactmech"/>
<response name="error" type="*view*" value="editcreditcard"/>
</request-map>

[*OPENTAPS*: controller.xml file on the crmsfa section]
<request-map uri="createCreditCard">
<security https="true" auth="true"/>
<event type="simple"
path="org/ofbiz/accounting/payment/PaymentMethodEvents.xml"
invoke="createCreditCard"/>
<response name="success" type="*request-redirect*"
value="donePageRequestHelper"/>
<response name="address" type="*request-redirect*"
value="donePageRequestHelper"/>
<response name="error" type="r*equest-redirect*"
value="donePageRequestHelper"/>
</request-map>

[Skipping donePageRequestHelper mapping part - I don't think it's necessary]

Service file involved ( line number could be varied depends on the
version you use):
[RequestHandler.java:719]
if (Debug.infoOn()) Debug.logInfo("Sending redirect to: [" + url + "],  
sessionId=" + UtilHttp.getSessionId(req), module);

How it will be printed on log file:
[Timestamp] (http-0.0.0.0-443-1) [  ServiceDispatcher.java:470:DEBUG]
Sync service [crmsfa/createCreditCard] finished in [98] milliseconds
[Timestamp] (http-0.0.0.0-443-1) [     RequestHandler.java:431:INFO ]
[RequestHandler.doRequest]: Response is a Request redirect.
sessionId=[Session ID]
[Timestamp] (http-0.0.0.0-443-1) [     RequestHandler.java:719:INFO ]
[Sending redirect]: /crmsfa/control/donePageRequestHelper?cardType=[Card
Type]&DONE_PAGE=crmsfaQuickCheckout&middleNameOnCard=&companyNameOnCard=&firstNameOnCard=*[Card
holder's First name]*&suffixOnCard=&titleOnCard=&lastNameOnCard=*[Card
holder's last name]*&expMonth=*[Expiration
date]*&description=&partyId=[partyId]&expYear=*[Expiration
date]*&contactMechId=[contactMechId]&cardNumber=*[Card number in plain
text]*&sessionId=[Session ID]


So here is my recommendation. If you're Opentaps user, please check the
"createCreditCard" method on controller.xml file of CRMSFA section. If
it uses "request-redirect" as response, please check the log file. There
would be highly likely a chance of printing out Credit Card information
on the log file.

Thank you for reading.

On 3/23/2012 7:20 AM, Paul Foxworthy wrote:

> Hi all,
>
> It's important that we don't log complete credit cards, so Jacques's
> fix is definitely an improvement.
>
> Might there be a need to log masked credit card numbers sometimes?
> Perhaps only at the verbose logging level? That ought to be enough to
> identify a specific transaction without the security risks of a
> complete credit card number.
>
> Jira OFBIZ-1687 introduced a method to mask all but the checksum for a
> credit card number, see the method formatPrintableCreditCard in
> framework/base/src/org/ofbiz/base/util/UtilFormatOut.java .
>
> Unfortunately fisheye is broken at present, but once it's back the
> fisheye URL is https://fisheye6.atlassian.com/browse/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/UtilFormatOut.java?hb=true
>
> I would prefer to see the issuer (i.e. the first six digits) as well
> as the checksum (the last four digits). There's example code to do
> that at http://adamcaudill.com/2011/10/20/masking-credit-cards-for-pci/
>
> The CVV number should not be stored or logged at all.
>
> What do people think?
>
> Cheers
>
> Paul Foxworthy
>
> Jacques Le Rous wrote:
> Hi Paul,
>
> As suggested in my answer to Vicky, I have commented out the line
> [PayflowPro.java:166]
> in trunk and ALL releases (including R4.0)
>
> Please Vicky could you please confirm that this change is enough for
> the other points you raised?
>
> Trunk test is enough because all the automatic backports worked well,
> which is not surprising because this is really an old
> adaptation to an external payment provider.
>
> Jacques
>
> Paul Piper wrote:
>> I also agree that this is probably a security issue and could mean that you
>> are not getting the proper validation by credit card companies. You need to
>> be accredited by credit card companies with PCI CSS to even be allowed to
>> support creditcard transaction directly (unless you use an external iPayment
>> service for this) and there you cannot store this sort of data in the logs.
>> Only xxxx-ed out credit card information should be used.
>>
>> ---
>> Paul Piper
>> Geschäftsführer
>>
>>
>> Web: http://www.ilscipio.com
>> Tel: [phone]
>> Mobil: ([phone]
>> Fax: [phone]
>> eMail:<email>pp@</email>
>>
>>
>> ilscipio GmbH
>> Am Drosselschlag 7
>> D-35452 Heuchelheim
>> Germany
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Jacques Le Roux [mailto:<email>jacques.le.roux@</email>]
>> Gesendet: Mittwoch, 21. März 2012 19:47
>> An:<email>user@.apache</email>
>> Betreff: Re: [Security Concern] Printing out credit card information on the
>> log file?
>>
>> From: "Vicky Park"&lt;<email>vicky@</email>&gt;
>>> Hello folks,
>>>
>>>
>>> I realized that printing some information on log files could violate
>>> PCI CSS (Payment Card Industry Data Security Standard) depends on how
>>> they configure the system, and how to use the log file. If I
>>> understood correctly, we're printing card holder's information
>>> including credit card number, expiration and CVV num in plain text on log file.
>>>
>>> If we don't print out on the log at all on the live site, that would
>>> solve the problem. But if there is a person who wasn't aware of that
>>> fact,  he might accidentally violate the PCI DSS compliance. For
>>> example, let's say there is a person who keeps the log to be printed
>>> on the live site. And for some reason, he downloaded log file to his
>>> local computer and kept unsafe location, or passed to someone else to
>>> let them take a look that log file for asking help. Then I believe he
>>> is violating the PCI CSS compliance accidentally.
>>>
>>>
>>> Code involved 1:
>>> [PayflowPro.java:166]
>>> if (Debug.verboseOn()) Debug.logVerbose("Sending to Verisign: " +
>>> params.toString(), module);
>>>
>>>
>>> Logs which is being printed:
>>> [Datetime] (TP-Processor70) [         PayflowPro.java:166:INFO ] Sending
>>> to Verisign: PARTNER=verisign&VENDOR=[Company
>>> ]&USER=[UserID]&PWD=[Password]&COMMENT1=[Order ID]&PONUM=[PO Order Id]
>>> &CUSTCODE=[Customer's code]&TRXTYPE=[]&TENDER=[]&CVV2=*[CVV
>>> number*]&AMT=[Amount]&ACCT=*[16 digit credit card number in plain
>>> text]*&FIRSTNAME=[Cardholder's firstname]&LASTNAME=[Card holder's last
>>> name]&COMMENT2=[]&EXPDATE=*[expiration date]*&STREET=[Card holder's
>>> address&ZIP=[card holder's zip code]
>>>
>>>
>>> Code involved 2:
>>> [RequestHandler.java:719]
>>> if (Debug.infoOn()) Debug.logInfo("Sending redirect to: [" + url + "],
>>> sessionId=" + UtilHttp.getSessionId(req), module);
>>>
>>> =>  I realized that credit card information is being printed from
>>> different file as well (RequestHandler.java:719). I need to check what
>>> service triggers RequestHandler.java:719 and passes credit card
>>> information within url variable. But at least I noticed sometimes that
>>> line in the log file contains credit card information in plain text as well.
>>>
>>>
>>> PCI DSS involved:
>>> 7. Restrict access to cardholder data by business need-to-know 9.
>>> Restrict physical access to cardholder data
>>> [Reference]http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec
>>> urity_Standard
>>>
>>>
>>>
>>> So, here is my questions&  recommendation:
>>>
>>> 1. As we (at least I) want to keep log for in case, I think it's
>>> better to not to print out credit card information to the log file.
>>> What do you think? Do you think deleting that line is the best option?
>> It's very unlikely that anybody would run a production server with log set
>> at verbose level at any moment for all classes/packages.
>> But we could easily comment out this line indeed (not deleting it)
>>
>>> 2.  If you guys think it's better to print out at least some
>>> information to log file for some purpose, I believe it's better to
>>> print out in encrypted format rather than in plain text. Otherwise we
>>> can print out last 4 digit or first 4 digit, not entire number.
>> Not needed if commentout, then people would be really aware that they are
>> sending it to log
>>
>>> 3. Do you know what triggers RequestHander to print out credit card
>>> information?
>> I expect commenting line in PayflowPro.java would be enough
>>
>>> 4. Is there any other file you can think of which likely print out
>>> credit card information to log file?
>> I don't think so. PayflowPro is not used OOTB in OFBiz IIRW
>>
>> Jacques
>>
>>> Hope it would be helpful for security improvement for myself and
>>> someone else who may use ofbiz on the live site.
>>>
>>>
>>> Thanks you for reading.
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Phone: [phone]
> Fax: [phone]
> Web: http://www.cohsoft.com.au/
> Email: [hidden email]
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>

[Jacques Le Roux]

Thanks for detailled report Vicky

Jacques

From: "Vicky Park" <[hidden email]>

> Good morning guys,
>
> Thanks for the commit. I believe that would be helpful for everybody.
>
> Sorry for late reply. I was working on that issue by myself as well, And
> there is one more comment I want to make to the Opentaps user. I do know
> it's ofbiz forum, but if you're using Opentaps, then there is one more
> thing you may want to check - I know there is similarity b/w two of the
> applications, and some of the Opentaps user use ofbiz forum as well.
> First part is what Paul commented out - Should be good. And second part
> is Redirect part which I mentioned earlier.
>
> I compared and tested ofbiz & opentaps both, and realized there was a
> difference b/w two applications in the usage of redirect. After I apply
> Paul's commit, I noticed Ofbiz doesn't print out credit card information
> anymore, but Opentaps still does.
>
> Here is what it happens. Opentaps use Redirect to handle the payment in
> one service(createCreditCard). And the variable is passed to the
> redirect handler, and redirect service print out all the variables
> received. "Printing out variables received" is not a problem itself. But
> combination with "Passing credit card info" could be the problem. And it
> turns out printing out credit card information on the log file in plain
> text again.
>
>
> Related code:
>
> [*OFBIZ*:  controller.xml file on the ordermgr section]
> <request-map uri="createCreditCard">
> <security https="true" auth="true"/>
> <event type="simple"
> path="component://accounting/script/org/ofbiz/accounting/payment/PaymentMethodEvents.xml"
> invoke="createCreditCard"/>
> <response name="success" type="*view*" value="editcreditcard"/>
> <response name="address" type="*view*" value="editcontactmech"/>
> <response name="error" type="*view*" value="editcreditcard"/>
> </request-map>
>
> [*OPENTAPS*: controller.xml file on the crmsfa section]
> <request-map uri="createCreditCard">
> <security https="true" auth="true"/>
> <event type="simple"
> path="org/ofbiz/accounting/payment/PaymentMethodEvents.xml"
> invoke="createCreditCard"/>
> <response name="success" type="*request-redirect*"
> value="donePageRequestHelper"/>
> <response name="address" type="*request-redirect*"
> value="donePageRequestHelper"/>
> <response name="error" type="r*equest-redirect*"
> value="donePageRequestHelper"/>
> </request-map>
>
> [Skipping donePageRequestHelper mapping part - I don't think it's necessary]
>
> Service file involved ( line number could be varied depends on the
> version you use):
> [RequestHandler.java:719]
> if (Debug.infoOn()) Debug.logInfo("Sending redirect to: [" + url + "],
> sessionId=" + UtilHttp.getSessionId(req), module);
>
> How it will be printed on log file:
> [Timestamp] (http-0.0.0.0-443-1) [  ServiceDispatcher.java:470:DEBUG]
> Sync service [crmsfa/createCreditCard] finished in [98] milliseconds
> [Timestamp] (http-0.0.0.0-443-1) [     RequestHandler.java:431:INFO ]
> [RequestHandler.doRequest]: Response is a Request redirect.
> sessionId=[Session ID]
> [Timestamp] (http-0.0.0.0-443-1) [     RequestHandler.java:719:INFO ]
> [Sending redirect]: /crmsfa/control/donePageRequestHelper?cardType=[Card
> Type]&DONE_PAGE=crmsfaQuickCheckout&middleNameOnCard=&companyNameOnCard=&firstNameOnCard=*[Card
> holder's First name]*&suffixOnCard=&titleOnCard=&lastNameOnCard=*[Card
> holder's last name]*&expMonth=*[Expiration
> date]*&description=&partyId=[partyId]&expYear=*[Expiration
> date]*&contactMechId=[contactMechId]&cardNumber=*[Card number in plain
> text]*&sessionId=[Session ID]
>
>
> So here is my recommendation. If you're Opentaps user, please check the
> "createCreditCard" method on controller.xml file of CRMSFA section. If
> it uses "request-redirect" as response, please check the log file. There
> would be highly likely a chance of printing out Credit Card information
> on the log file.
>
> Thank you for reading.
>
> On 3/23/2012 7:20 AM, Paul Foxworthy wrote:
>> Hi all,
>>
>> It's important that we don't log complete credit cards, so Jacques's
>> fix is definitely an improvement.
>>
>> Might there be a need to log masked credit card numbers sometimes?
>> Perhaps only at the verbose logging level? That ought to be enough to
>> identify a specific transaction without the security risks of a
>> complete credit card number.
>>
>> Jira OFBIZ-1687 introduced a method to mask all but the checksum for a
>> credit card number, see the method formatPrintableCreditCard in
>> framework/base/src/org/ofbiz/base/util/UtilFormatOut.java .
>>
>> Unfortunately fisheye is broken at present, but once it's back the
>> fisheye URL is
>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/UtilFormatOut.java?hb=true
>>
>> I would prefer to see the issuer (i.e. the first six digits) as well
>> as the checksum (the last four digits). There's example code to do
>> that at http://adamcaudill.com/2011/10/20/masking-credit-cards-for-pci/
>>
>> The CVV number should not be stored or logged at all.
>>
>> What do people think?
>>
>> Cheers
>>
>> Paul Foxworthy
>>
>> Jacques Le Rous wrote:
>> Hi Paul,
>>
>> As suggested in my answer to Vicky, I have commented out the line
>> [PayflowPro.java:166]
>> in trunk and ALL releases (including R4.0)
>>
>> Please Vicky could you please confirm that this change is enough for
>> the other points you raised?
>>
>> Trunk test is enough because all the automatic backports worked well,
>> which is not surprising because this is really an old
>> adaptation to an external payment provider.
>>
>> Jacques
>>
>> Paul Piper wrote:
>>> I also agree that this is probably a security issue and could mean that you
>>> are not getting the proper validation by credit card companies. You need to
>>> be accredited by credit card companies with PCI CSS to even be allowed to
>>> support creditcard transaction directly (unless you use an external iPayment
>>> service for this) and there you cannot store this sort of data in the logs.
>>> Only xxxx-ed out credit card information should be used.
>>>
>>> ---
>>> Paul Piper
>>> Geschäftsführer
>>>
>>>
>>> Web: http://www.ilscipio.com
>>> Tel: [phone]
>>> Mobil: ([phone]
>>> Fax: [phone]
>>> eMail:<email>pp@</email>
>>>
>>>
>>> ilscipio GmbH
>>> Am Drosselschlag 7
>>> D-35452 Heuchelheim
>>> Germany
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Jacques Le Roux [mailto:<email>jacques.le.roux@</email>]
>>> Gesendet: Mittwoch, 21. März 2012 19:47
>>> An:<email>user@.apache</email>
>>> Betreff: Re: [Security Concern] Printing out credit card information on the
>>> log file?
>>>
>>> From: "Vicky Park"&lt;<email>vicky@</email>&gt;
>>>> Hello folks,
>>>>
>>>>
>>>> I realized that printing some information on log files could violate
>>>> PCI CSS (Payment Card Industry Data Security Standard) depends on how
>>>> they configure the system, and how to use the log file. If I
>>>> understood correctly, we're printing card holder's information
>>>> including credit card number, expiration and CVV num in plain text on log file.
>>>>
>>>> If we don't print out on the log at all on the live site, that would
>>>> solve the problem. But if there is a person who wasn't aware of that
>>>> fact,  he might accidentally violate the PCI DSS compliance. For
>>>> example, let's say there is a person who keeps the log to be printed
>>>> on the live site. And for some reason, he downloaded log file to his
>>>> local computer and kept unsafe location, or passed to someone else to
>>>> let them take a look that log file for asking help. Then I believe he
>>>> is violating the PCI CSS compliance accidentally.
>>>>
>>>>
>>>> Code involved 1:
>>>> [PayflowPro.java:166]
>>>> if (Debug.verboseOn()) Debug.logVerbose("Sending to Verisign: " +
>>>> params.toString(), module);
>>>>
>>>>
>>>> Logs which is being printed:
>>>> [Datetime] (TP-Processor70) [         PayflowPro.java:166:INFO ] Sending
>>>> to Verisign: PARTNER=verisign&VENDOR=[Company
>>>> ]&USER=[UserID]&PWD=[Password]&COMMENT1=[Order ID]&PONUM=[PO Order Id]
>>>> &CUSTCODE=[Customer's code]&TRXTYPE=[]&TENDER=[]&CVV2=*[CVV
>>>> number*]&AMT=[Amount]&ACCT=*[16 digit credit card number in plain
>>>> text]*&FIRSTNAME=[Cardholder's firstname]&LASTNAME=[Card holder's last
>>>> name]&COMMENT2=[]&EXPDATE=*[expiration date]*&STREET=[Card holder's
>>>> address&ZIP=[card holder's zip code]
>>>>
>>>>
>>>> Code involved 2:
>>>> [RequestHandler.java:719]
>>>> if (Debug.infoOn()) Debug.logInfo("Sending redirect to: [" + url + "],
>>>> sessionId=" + UtilHttp.getSessionId(req), module);
>>>>
>>>> =>  I realized that credit card information is being printed from
>>>> different file as well (RequestHandler.java:719). I need to check what
>>>> service triggers RequestHandler.java:719 and passes credit card
>>>> information within url variable. But at least I noticed sometimes that
>>>> line in the log file contains credit card information in plain text as well.
>>>>
>>>>
>>>> PCI DSS involved:
>>>> 7. Restrict access to cardholder data by business need-to-know 9.
>>>> Restrict physical access to cardholder data
>>>> [Reference]http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec
>>>> urity_Standard
>>>>
>>>>
>>>>
>>>> So, here is my questions&  recommendation:
>>>>
>>>> 1. As we (at least I) want to keep log for in case, I think it's
>>>> better to not to print out credit card information to the log file.
>>>> What do you think? Do you think deleting that line is the best option?
>>> It's very unlikely that anybody would run a production server with log set
>>> at verbose level at any moment for all classes/packages.
>>> But we could easily comment out this line indeed (not deleting it)
>>>
>>>> 2.  If you guys think it's better to print out at least some
>>>> information to log file for some purpose, I believe it's better to
>>>> print out in encrypted format rather than in plain text. Otherwise we
>>>> can print out last 4 digit or first 4 digit, not entire number.
>>> Not needed if commentout, then people would be really aware that they are
>>> sending it to log
>>>
>>>> 3. Do you know what triggers RequestHander to print out credit card
>>>> information?
>>> I expect commenting line in PayflowPro.java would be enough
>>>
>>>> 4. Is there any other file you can think of which likely print out
>>>> credit card information to log file?
>>> I don't think so. PayflowPro is not used OOTB in OFBiz IIRW
>>>
>>> Jacques
>>>
>>>> Hope it would be helpful for security improvement for myself and
>>>> someone else who may use ofbiz on the live site.
>>>>
>>>>
>>>> Thanks you for reading.
>>
>> --
>> Coherent Software Australia Pty Ltd
>> PO Box 2773
>> Cheltenham Vic 3192
>> Phone: [phone]
>> Fax: [phone]
>> Web: http://www.cohsoft.com.au/
>> Email: [hidden email]
>>
>> Bonsai ERP, the all-inclusive ERP system
>> http://www.bonsaierp.com.au/
>>
>
>

[Jacques Le Roux]

Sorry I tried the point Heidi submitted (search not working) and I did not reproduce.
For your case, I'd need a clear process with each steps to validate that there is really an issue...

Jacques

From: "Jacques Le Roux" <[hidden email]>

> Yes that was here http://markmail.org/message/7jju5vtwooybywml
> Time to create a Jira, could you do it for me Jeremy?
> You can use the details you gave below
>
> Thanks
>
> Jacques
>
>
> From: "Jacques Le Roux" <[hidden email]>
>> Mmm... indeed, IIRW something like that has been reported lately. I don't remember if we created a Jira. I will have a look and
>> will create one if needed
>>
>> Jacques
>>
>> Jeremy Olmstead wrote:
>>> Well, sort of.  I used the information to initially bulk load data into
>>> Catalog/Category/Product, etc.  It was later that I decided I needed a
>>> different break down on the e-commerce site and that not all products
>>> should be on the web.  I deleted the initial catalog from the web store and
>>> put a new manually created web specific catalog up as the catalog for the
>>> web store.  I actually thought this is all I should have needed to do, but
>>> it didn't work, I still get all of the initial data.  Then I changed the
>>> internal catalog type to View Allow instead of Browse Root and even changed
>>> every category type to Internal instead of catalog.  At least the correct
>>> categories now show up on the left side navigation, but even there, when I
>>> drill down to a specific product and click the product detail link from the
>>> drill down it still shows me the product as if it is from the internal
>>> catalog!  I stopped the server and restarted MySql thinking it was some
>>> kind of caching issue, but I still have the same problem.
>>>
>>> Jeremy
>>>
>>> On Wed, Mar 21, 2012 at 9:32 AM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> Did you try https://cwiki.apache.org/**confluence/display/OFBENDUSER/**
>>>> Apache+OFBiz+Business+Setup+**Guide#**ApacheOFBizBusinessSetupGuide-**
>>>> catalogCategoryProductSetup<https://cwiki.apache.org/confluence/display/OFBENDUSER/Apache+OFBiz+Business+Setup+Guide#ApacheOFBizBusinessSetupGuide-catalogCategoryProductSetup>?
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Jeremy Olmstead wrote:
>>>>
>>>>> I have done this, but something is still not right.  How do I set my
>>>>> internal catalog to not show on the web?  When I do a search or even a
>>>>> direct link, my internal catalog items still show up on the e-commerce
>>>>> site.
>>>>>
>>>>> On Wed, Mar 21, 2012 at 8:59 AM, Jose F. Fernandez
>>>>> <[hidden email]>**wrote:
>>>>>
>>>>>  Hi Jeremy,
>>>>>>
>>>>>> you can create many catalogs (Application CATALOG MANAGER - Catalogs).
>>>>>> In the new created catalog you can tell in wich stores it may be visible
>>>>>> and associate the product categories for that catalog.
>>>>>> I recommend that you create a new product categories tree for the
>>>>>> e-commerce site.
>>>>>> That tree must be under a root category with type "Browse Root (One)" and
>>>>>> that root category is what you assign to your catalog.
>>>>>>
>>>>>> Look at the example catalogs for reference.
>>>>>>
>>>>>> Best regards,
>>>>>> Jose F.
>>>>>>
>>>>>>
>>>>>> ----- Mensaje original -----
>>>>>>
>>>>>>  De: "Jeremy Olmstead" <[hidden email]>
>>>>>>> Para: [hidden email]
>>>>>>> Enviados: Miércoles, 21 de Marzo 2012 14:34:32
>>>>>>> Asunto: Multiple Catalogs
>>>>>>>
>>>>>>
>>>>>>  I am not sure if this functionality is available OOTB. If it is,
>>>>>>> could
>>>>>>> someone let me know, and if it is not, could someone point me in the
>>>>>>> right
>>>>>>> direction on how this may be accomplished? What I would like to be
>>>>>>> able to
>>>>>>> do is have two catalogs with totally different break downs in
>>>>>>> categories.
>>>>>>> One would be for internal purposes and the other for e-commerce
>>>>>>> purposes.
>>>>>>> All products would be in the internal catalog and all items there
>>>>>>> should
>>>>>>> be able to be ordered, but not necessarily from the e-commerce site.
>>>>>>> The
>>>>>>> e-commerce catalog would be a subset of the internal catalog products
>>>>>>> and
>>>>>>> all items in there would be available for order internally and on
>>>>>>> e-commerce. This is mainly for product breakdown navigation, but also
>>>>>>> there are some products we don't want to sell on the Internet. Thanks
>>>>>>> for
>>>>>>> any help.
>>>>>>>
>>>>>>
>>>>>>  Jeremy

[Jacques Le Roux]

From: "Paul Foxworthy" <[hidden email]>

> Hi all,
>
> It's important that we don't log complete credit cards, so Jacques's
> fix is definitely an improvement.
>
> Might there be a need to log masked credit card numbers sometimes?
> Perhaps only at the verbose logging level? That ought to be enough to
> identify a specific transaction without the security risks of a
> complete credit card number.
>
> Jira OFBIZ-1687 introduced a method to mask all but the checksum for a
> credit card number, see the method formatPrintableCreditCard in
> framework/base/src/org/ofbiz/base/util/UtilFormatOut.java .
>
> Unfortunately fisheye is broken at present, but once it's back the
> fisheye URL is https://fisheye6.atlassian.com/browse/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/UtilFormatOut.java?hb=true
>
> I would prefer to see the issuer (i.e. the first six digits) as well
> as the checksum (the last four digits). There's example code to do
> that at http://adamcaudill.com/2011/10/20/masking-credit-cards-for-pci/
>
> The CVV number should not be stored or logged at all.
>
> What do people think?

Hi Paul,

Makes sense, please create a Jira, with patch if possible

Thanks

Jacques

> Cheers
>
> Paul Foxworthy
>
> Jacques Le Rous wrote:
> Hi Paul,
>
> As suggested in my answer to Vicky, I have commented out the line
> [PayflowPro.java:166]
> in trunk and ALL releases (including R4.0)
>
> Please Vicky could you please confirm that this change is enough for
> the other points you raised?
>
> Trunk test is enough because all the automatic backports worked well,
> which is not surprising because this is really an old
> adaptation to an external payment provider.
>
> Jacques
>
> Paul Piper wrote:
>> I also agree that this is probably a security issue and could mean that you
>> are not getting the proper validation by credit card companies. You need to
>> be accredited by credit card companies with PCI CSS to even be allowed to
>> support creditcard transaction directly (unless you use an external iPayment
>> service for this) and there you cannot store this sort of data in the logs.
>> Only xxxx-ed out credit card information should be used.
>>
>> ---
>> Paul Piper
>> Geschäftsführer
>>
>>
>> Web: http://www.ilscipio.com
>> Tel: [phone]
>> Mobil: ([phone]
>> Fax: [phone]
>> eMail: <email>pp@</email>
>>
>>
>> ilscipio GmbH
>> Am Drosselschlag 7
>> D-35452 Heuchelheim
>> Germany
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Jacques Le Roux [mailto:<email>jacques.le.roux@</email>]
>> Gesendet: Mittwoch, 21. März 2012 19:47
>> An: <email>user@.apache</email>
>> Betreff: Re: [Security Concern] Printing out credit card information on the
>> log file?
>>
>> From: "Vicky Park" &lt;<email>vicky@</email>&gt;
>>> Hello folks,
>>>
>>>
>>> I realized that printing some information on log files could violate
>>> PCI CSS (Payment Card Industry Data Security Standard) depends on how
>>> they configure the system, and how to use the log file. If I
>>> understood correctly, we're printing card holder's information
>>> including credit card number, expiration and CVV num in plain text on log file.
>>>
>>> If we don't print out on the log at all on the live site, that would
>>> solve the problem. But if there is a person who wasn't aware of that
>>> fact, he might accidentally violate the PCI DSS compliance. For
>>> example, let's say there is a person who keeps the log to be printed
>>> on the live site. And for some reason, he downloaded log file to his
>>> local computer and kept unsafe location, or passed to someone else to
>>> let them take a look that log file for asking help. Then I believe he
>>> is violating the PCI CSS compliance accidentally.
>>>
>>>
>>> Code involved 1:
>>> [PayflowPro.java:166]
>>> if (Debug.verboseOn()) Debug.logVerbose("Sending to Verisign: " +
>>> params.toString(), module);
>>>
>>>
>>> Logs which is being printed:
>>> [Datetime] (TP-Processor70) [ PayflowPro.java:166:INFO ] Sending
>>> to Verisign: PARTNER=verisign&VENDOR=[Company
>>> ]&USER=[UserID]&PWD=[Password]&COMMENT1=[Order ID]&PONUM=[PO Order Id]
>>> &CUSTCODE=[Customer's code]&TRXTYPE=[]&TENDER=[]&CVV2=*[CVV
>>> number*]&AMT=[Amount]&ACCT=*[16 digit credit card number in plain
>>> text]*&FIRSTNAME=[Cardholder's firstname]&LASTNAME=[Card holder's last
>>> name]&COMMENT2=[]&EXPDATE=*[expiration date]*&STREET=[Card holder's
>>> address&ZIP=[card holder's zip code]
>>>
>>>
>>> Code involved 2:
>>> [RequestHandler.java:719]
>>> if (Debug.infoOn()) Debug.logInfo("Sending redirect to: [" + url + "],
>>> sessionId=" + UtilHttp.getSessionId(req), module);
>>>
>>> => I realized that credit card information is being printed from
>>> different file as well (RequestHandler.java:719). I need to check what
>>> service triggers RequestHandler.java:719 and passes credit card
>>> information within url variable. But at least I noticed sometimes that
>>> line in the log file contains credit card information in plain text as well.
>>>
>>>
>>> PCI DSS involved:
>>> 7. Restrict access to cardholder data by business need-to-know 9.
>>> Restrict physical access to cardholder data
>>> [Reference]http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec
>>> urity_Standard
>>>
>>>
>>>
>>> So, here is my questions & recommendation:
>>>
>>> 1. As we (at least I) want to keep log for in case, I think it's
>>> better to not to print out credit card information to the log file.
>>> What do you think? Do you think deleting that line is the best option?
>>
>> It's very unlikely that anybody would run a production server with log set
>> at verbose level at any moment for all classes/packages.
>> But we could easily comment out this line indeed (not deleting it)
>>
>>> 2. If you guys think it's better to print out at least some
>>> information to log file for some purpose, I believe it's better to
>>> print out in encrypted format rather than in plain text. Otherwise we
>>> can print out last 4 digit or first 4 digit, not entire number.
>>
>> Not needed if commentout, then people would be really aware that they are
>> sending it to log
>>
>>> 3. Do you know what triggers RequestHander to print out credit card
>>> information?
>>
>> I expect commenting line in PayflowPro.java would be enough
>>
>>> 4. Is there any other file you can think of which likely print out
>>> credit card information to log file?
>>
>> I don't think so. PayflowPro is not used OOTB in OFBiz IIRW
>>
>> Jacques
>>
>>>
>>> Hope it would be helpful for security improvement for myself and
>>> someone else who may use ofbiz on the live site.
>>>
>>>
>>> Thanks you for reading.
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Phone: [phone]
> Fax: [phone]
> Web: http://www.cohsoft.com.au/
> Email: [hidden email]
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>

[Jacques Le Roux]

Last minute note: for now UtilFormatOut.formatPrintableCreditCard(cardNum) is only used in POS...

Are you sure it's required elsewhere?

Jacques

From: "Jacques Le Roux" <[hidden email]>

> From: "Paul Foxworthy" <[hidden email]>
>> Hi all,
>>
>> It's important that we don't log complete credit cards, so Jacques's
>> fix is definitely an improvement.
>>
>> Might there be a need to log masked credit card numbers sometimes?
>> Perhaps only at the verbose logging level? That ought to be enough to
>> identify a specific transaction without the security risks of a
>> complete credit card number.
>>
>> Jira OFBIZ-1687 introduced a method to mask all but the checksum for a
>> credit card number, see the method formatPrintableCreditCard in
>> framework/base/src/org/ofbiz/base/util/UtilFormatOut.java .
>>
>> Unfortunately fisheye is broken at present, but once it's back the
>> fisheye URL is
>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/UtilFormatOut.java?hb=true
>>
>> I would prefer to see the issuer (i.e. the first six digits) as well
>> as the checksum (the last four digits). There's example code to do
>> that at http://adamcaudill.com/2011/10/20/masking-credit-cards-for-pci/
>>
>> The CVV number should not be stored or logged at all.
>>
>> What do people think?
>
> Hi Paul,
>
> Makes sense, please create a Jira, with patch if possible
>
> Thanks
>
> Jacques
>
>> Cheers
>>
>> Paul Foxworthy
>>
>> Jacques Le Rous wrote:
>> Hi Paul,
>>
>> As suggested in my answer to Vicky, I have commented out the line
>> [PayflowPro.java:166]
>> in trunk and ALL releases (including R4.0)
>>
>> Please Vicky could you please confirm that this change is enough for
>> the other points you raised?
>>
>> Trunk test is enough because all the automatic backports worked well,
>> which is not surprising because this is really an old
>> adaptation to an external payment provider.
>>
>> Jacques
>>
>> Paul Piper wrote:
>>> I also agree that this is probably a security issue and could mean that you
>>> are not getting the proper validation by credit card companies. You need to
>>> be accredited by credit card companies with PCI CSS to even be allowed to
>>> support creditcard transaction directly (unless you use an external iPayment
>>> service for this) and there you cannot store this sort of data in the logs.
>>> Only xxxx-ed out credit card information should be used.
>>>
>>> ---
>>> Paul Piper
>>> Geschäftsführer
>>>
>>>
>>> Web: http://www.ilscipio.com
>>> Tel: [phone]
>>> Mobil: ([phone]
>>> Fax: [phone]
>>> eMail: <email>pp@</email>
>>>
>>>
>>> ilscipio GmbH
>>> Am Drosselschlag 7
>>> D-35452 Heuchelheim
>>> Germany
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Jacques Le Roux [mailto:<email>jacques.le.roux@</email>]
>>> Gesendet: Mittwoch, 21. März 2012 19:47
>>> An: <email>user@.apache</email>
>>> Betreff: Re: [Security Concern] Printing out credit card information on the
>>> log file?
>>>
>>> From: "Vicky Park" &lt;<email>vicky@</email>&gt;
>>>> Hello folks,
>>>>
>>>>
>>>> I realized that printing some information on log files could violate
>>>> PCI CSS (Payment Card Industry Data Security Standard) depends on how
>>>> they configure the system, and how to use the log file. If I
>>>> understood correctly, we're printing card holder's information
>>>> including credit card number, expiration and CVV num in plain text on log file.
>>>>
>>>> If we don't print out on the log at all on the live site, that would
>>>> solve the problem. But if there is a person who wasn't aware of that
>>>> fact, he might accidentally violate the PCI DSS compliance. For
>>>> example, let's say there is a person who keeps the log to be printed
>>>> on the live site. And for some reason, he downloaded log file to his
>>>> local computer and kept unsafe location, or passed to someone else to
>>>> let them take a look that log file for asking help. Then I believe he
>>>> is violating the PCI CSS compliance accidentally.
>>>>
>>>>
>>>> Code involved 1:
>>>> [PayflowPro.java:166]
>>>> if (Debug.verboseOn()) Debug.logVerbose("Sending to Verisign: " +
>>>> params.toString(), module);
>>>>
>>>>
>>>> Logs which is being printed:
>>>> [Datetime] (TP-Processor70) [ PayflowPro.java:166:INFO ] Sending
>>>> to Verisign: PARTNER=verisign&VENDOR=[Company
>>>> ]&USER=[UserID]&PWD=[Password]&COMMENT1=[Order ID]&PONUM=[PO Order Id]
>>>> &CUSTCODE=[Customer's code]&TRXTYPE=[]&TENDER=[]&CVV2=*[CVV
>>>> number*]&AMT=[Amount]&ACCT=*[16 digit credit card number in plain
>>>> text]*&FIRSTNAME=[Cardholder's firstname]&LASTNAME=[Card holder's last
>>>> name]&COMMENT2=[]&EXPDATE=*[expiration date]*&STREET=[Card holder's
>>>> address&ZIP=[card holder's zip code]
>>>>
>>>>
>>>> Code involved 2:
>>>> [RequestHandler.java:719]
>>>> if (Debug.infoOn()) Debug.logInfo("Sending redirect to: [" + url + "],
>>>> sessionId=" + UtilHttp.getSessionId(req), module);
>>>>
>>>> => I realized that credit card information is being printed from
>>>> different file as well (RequestHandler.java:719). I need to check what
>>>> service triggers RequestHandler.java:719 and passes credit card
>>>> information within url variable. But at least I noticed sometimes that
>>>> line in the log file contains credit card information in plain text as well.
>>>>
>>>>
>>>> PCI DSS involved:
>>>> 7. Restrict access to cardholder data by business need-to-know 9.
>>>> Restrict physical access to cardholder data
>>>> [Reference]http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec
>>>> urity_Standard
>>>>
>>>>
>>>>
>>>> So, here is my questions & recommendation:
>>>>
>>>> 1. As we (at least I) want to keep log for in case, I think it's
>>>> better to not to print out credit card information to the log file.
>>>> What do you think? Do you think deleting that line is the best option?
>>>
>>> It's very unlikely that anybody would run a production server with log set
>>> at verbose level at any moment for all classes/packages.
>>> But we could easily comment out this line indeed (not deleting it)
>>>
>>>> 2. If you guys think it's better to print out at least some
>>>> information to log file for some purpose, I believe it's better to
>>>> print out in encrypted format rather than in plain text. Otherwise we
>>>> can print out last 4 digit or first 4 digit, not entire number.
>>>
>>> Not needed if commentout, then people would be really aware that they are
>>> sending it to log
>>>
>>>> 3. Do you know what triggers RequestHander to print out credit card
>>>> information?
>>>
>>> I expect commenting line in PayflowPro.java would be enough
>>>
>>>> 4. Is there any other file you can think of which likely print out
>>>> credit card information to log file?
>>>
>>> I don't think so. PayflowPro is not used OOTB in OFBiz IIRW
>>>
>>> Jacques
>>>
>>>>
>>>> Hope it would be helpful for security improvement for myself and
>>>> someone else who may use ofbiz on the live site.
>>>>
>>>>
>>>> Thanks you for reading.
>>
>>
>> --
>> Coherent Software Australia Pty Ltd
>> PO Box 2773
>> Cheltenham Vic 3192
>> Phone: [phone]
>> Fax: [phone]
>> Web: http://www.cohsoft.com.au/
>> Email: [hidden email]
>>
>> Bonsai ERP, the all-inclusive ERP system
>> http://www.bonsaierp.com.au/
>>
>

[Jacques Le Roux]

Oops, did not notice Jeremy created a Jira https://issues.apache.org/jira/browse/OFBIZ-4755
Please add your comments/steps there

Thanks Jeremy

Jacques

From: "Jacques Le Roux" <[hidden email]>

> Sorry I tried the point Heidi submitted (search not working) and I did not reproduce.
> For your case, I'd need a clear process with each steps to validate that there is really an issue...
>
> Jacques
>
> From: "Jacques Le Roux" <[hidden email]>
>> Yes that was here http://markmail.org/message/7jju5vtwooybywml
>> Time to create a Jira, could you do it for me Jeremy?
>> You can use the details you gave below
>>
>> Thanks
>>
>> Jacques
>>
>>
>> From: "Jacques Le Roux" <[hidden email]>
>>> Mmm... indeed, IIRW something like that has been reported lately. I don't remember if we created a Jira. I will have a look and
>>> will create one if needed
>>>
>>> Jacques
>>>
>>> Jeremy Olmstead wrote:
>>>> Well, sort of.  I used the information to initially bulk load data into
>>>> Catalog/Category/Product, etc.  It was later that I decided I needed a
>>>> different break down on the e-commerce site and that not all products
>>>> should be on the web.  I deleted the initial catalog from the web store and
>>>> put a new manually created web specific catalog up as the catalog for the
>>>> web store.  I actually thought this is all I should have needed to do, but
>>>> it didn't work, I still get all of the initial data.  Then I changed the
>>>> internal catalog type to View Allow instead of Browse Root and even changed
>>>> every category type to Internal instead of catalog.  At least the correct
>>>> categories now show up on the left side navigation, but even there, when I
>>>> drill down to a specific product and click the product detail link from the
>>>> drill down it still shows me the product as if it is from the internal
>>>> catalog!  I stopped the server and restarted MySql thinking it was some
>>>> kind of caching issue, but I still have the same problem.
>>>>
>>>> Jeremy
>>>>
>>>> On Wed, Mar 21, 2012 at 9:32 AM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>>> Did you try https://cwiki.apache.org/**confluence/display/OFBENDUSER/**
>>>>> Apache+OFBiz+Business+Setup+**Guide#**ApacheOFBizBusinessSetupGuide-**
>>>>> catalogCategoryProductSetup<https://cwiki.apache.org/confluence/display/OFBENDUSER/Apache+OFBiz+Business+Setup+Guide#ApacheOFBizBusinessSetupGuide-catalogCategoryProductSetup>?
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Jeremy Olmstead wrote:
>>>>>
>>>>>> I have done this, but something is still not right.  How do I set my
>>>>>> internal catalog to not show on the web?  When I do a search or even a
>>>>>> direct link, my internal catalog items still show up on the e-commerce
>>>>>> site.
>>>>>>
>>>>>> On Wed, Mar 21, 2012 at 8:59 AM, Jose F. Fernandez
>>>>>> <[hidden email]>**wrote:
>>>>>>
>>>>>>  Hi Jeremy,
>>>>>>>
>>>>>>> you can create many catalogs (Application CATALOG MANAGER - Catalogs).
>>>>>>> In the new created catalog you can tell in wich stores it may be visible
>>>>>>> and associate the product categories for that catalog.
>>>>>>> I recommend that you create a new product categories tree for the
>>>>>>> e-commerce site.
>>>>>>> That tree must be under a root category with type "Browse Root (One)" and
>>>>>>> that root category is what you assign to your catalog.
>>>>>>>
>>>>>>> Look at the example catalogs for reference.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Jose F.
>>>>>>>
>>>>>>>
>>>>>>> ----- Mensaje original -----
>>>>>>>
>>>>>>>  De: "Jeremy Olmstead" <[hidden email]>
>>>>>>>> Para: [hidden email]
>>>>>>>> Enviados: Miércoles, 21 de Marzo 2012 14:34:32
>>>>>>>> Asunto: Multiple Catalogs
>>>>>>>>
>>>>>>>
>>>>>>>  I am not sure if this functionality is available OOTB. If it is,
>>>>>>>> could
>>>>>>>> someone let me know, and if it is not, could someone point me in the
>>>>>>>> right
>>>>>>>> direction on how this may be accomplished? What I would like to be
>>>>>>>> able to
>>>>>>>> do is have two catalogs with totally different break downs in
>>>>>>>> categories.
>>>>>>>> One would be for internal purposes and the other for e-commerce
>>>>>>>> purposes.
>>>>>>>> All products would be in the internal catalog and all items there
>>>>>>>> should
>>>>>>>> be able to be ordered, but not necessarily from the e-commerce site.
>>>>>>>> The
>>>>>>>> e-commerce catalog would be a subset of the internal catalog products
>>>>>>>> and
>>>>>>>> all items in there would be available for order internally and on
>>>>>>>> e-commerce. This is mainly for product breakdown navigation, but also
>>>>>>>> there are some products we don't want to sell on the Internet. Thanks
>>>>>>>> for
>>>>>>>> any help.
>>>>>>>>
>>>>>>>
>>>>>>>  Jeremy