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 |
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 |
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 > |
Administrator
|
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 |
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. |
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. > |
Administrator
|
In reply to this post by Vicky Park
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. > > |
In reply to this post by Jacques Le Roux
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 >>>> >>> |
In reply to this post by Jacques Le Roux
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: (+49) 611-94589441 Mobil: (+49) 176-63283066 Fax: (+49) 611-94589449 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 > > > 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. > > |
Administrator
|
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: (+49) 611-94589441 > Mobil: (+49) 176-63283066 > Fax: (+49) 611-94589449 > 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. |
Administrator
|
In reply to this post by Jeremy Olmstead
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 |
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 |
In reply to this post by Jeremy Olmstead
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: (+49) 611-94589441 > Mobil: (+49) 176-63283066 > Fax: (+49) 611-94589449 > 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" <<email>vicky@</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. -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: [hidden email] Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
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: (+49) 611-94589441 >> Mobil: (+49) 176-63283066 >> Fax: (+49) 611-94589449 >> 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"<<email>vicky@</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. > > -- > Coherent Software Australia Pty Ltd > PO Box 2773 > Cheltenham Vic 3192 > Phone: (03) 9585 6788 > Fax: (03) 9585 1086 > Web: http://www.cohsoft.com.au/ > Email: [hidden email] > > Bonsai ERP, the all-inclusive ERP system > http://www.bonsaierp.com.au/ > |
Administrator
|
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: (+49) 611-94589441 >>> Mobil: (+49) 176-63283066 >>> Fax: (+49) 611-94589449 >>> 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"<<email>vicky@</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. >> >> -- >> Coherent Software Australia Pty Ltd >> PO Box 2773 >> Cheltenham Vic 3192 >> Phone: (03) 9585 6788 >> Fax: (03) 9585 1086 >> Web: http://www.cohsoft.com.au/ >> Email: [hidden email] >> >> Bonsai ERP, the all-inclusive ERP system >> http://www.bonsaierp.com.au/ >> > > |
Administrator
|
In reply to this post by Jacques Le Roux-3
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 |
Administrator
|
In reply to this post by Paul Foxworthy
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: (+49) 611-94589441 >> Mobil: (+49) 176-63283066 >> Fax: (+49) 611-94589449 >> 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" <<email>vicky@</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. > > > -- > Coherent Software Australia Pty Ltd > PO Box 2773 > Cheltenham Vic 3192 > Phone: (03) 9585 6788 > Fax: (03) 9585 1086 > Web: http://www.cohsoft.com.au/ > Email: [hidden email] > > Bonsai ERP, the all-inclusive ERP system > http://www.bonsaierp.com.au/ > |
Administrator
|
In reply to this post by Jeremy Olmstead
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: (+49) 611-94589441 >>> Mobil: (+49) 176-63283066 >>> Fax: (+49) 611-94589449 >>> 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" <<email>vicky@</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. >> >> >> -- >> Coherent Software Australia Pty Ltd >> PO Box 2773 >> Cheltenham Vic 3192 >> Phone: (03) 9585 6788 >> Fax: (03) 9585 1086 >> Web: http://www.cohsoft.com.au/ >> Email: [hidden email] >> >> Bonsai ERP, the all-inclusive ERP system >> http://www.bonsaierp.com.au/ >> > |
Administrator
|
In reply to this post by 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 |
Free forum by Nabble | Edit this page |