|
Description
Kyle M Hall (khall)
2015-11-02 17:11:03 UTC
Created attachment 44289 [details] [review] Bug 15111 - Koha is vulnerable to Cross-Frame Scripting (XFS) attacks Web pages that can be embedded in frames are vulnerable to cross-frame scripting attacks. Cross-frame scripting is a type of phishing attack that involves instructions to an unsuspecting user to follow a specific link to update confidential information in an online application. Because the link leads to a legitimate page from the online application that is embedded in a frame hosted by the attackers' server, the attackers can capture all the information that the user enters. https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet *** Bug 11778 has been marked as a duplicate of this bug. *** Created attachment 44339 [details] [review] Bug 15111 - Koha is vulnerable to Cross-Frame Scripting (XFS) attacks Web pages that can be embedded in frames are vulnerable to cross-frame scripting attacks. Cross-frame scripting is a type of phishing attack that involves instructions to an unsuspecting user to follow a specific link to update confidential information in an online application. Because the link leads to a legitimate page from the online application that is embedded in a frame hosted by the attackers' server, the attackers can capture all the information that the user enters. https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Can I please get a test plan for this? What are the side effects? Does it mean Koha can generally not be run in a frame? (In reply to Katrin Fischer from comment #4) > Can I please get a test plan for this? > What are the side effects? Does it mean Koha can generally not be run in a > frame? To test: Browse to http://1dn.eu/iframe.asp?url=URL where URL is the url to your Koha server. It your server is vulnerable to XFS attacks you will be able to see it in the frame, if it is empty, your site is safe from XFS attacks. You can also test with sites like google.com and yahoo.com. Generally any site that allows you to log in is especially vulnerable to XFS attacks as an attacker can use the frame to capture your username and password as you type it. Yes, that is correct. It makes sense to follow security guidelines - no question there. But shoudl we put a warning in the release notes? It might be that people have used iframes to integrate the OPAC into their websites. (In reply to Katrin Fischer from comment #6) > It makes sense to follow security guidelines - no question there. But shoudl > we put a warning in the release notes? It might be that people have used > iframes to integrate the OPAC into their websites. That sounds fine by me! Only one problem for me - I don't have a Koha installation that is not "localhost" that I can test with - so I can't test with the website you recommended. (In reply to Katrin Fischer from comment #8) > Only one problem for me - I don't have a Koha installation that is not > "localhost" that I can test with - so I can't test with the website you > recommended. Have you tried it? That should not be a problem! I was able to test my own local installation using that tool. Created attachment 44622 [details] [review] [PASSED QA] Bug 15111 - Koha is vulnerable to Cross-Frame Scripting (XFS) attacks Web pages that can be embedded in frames are vulnerable to cross-frame scripting attacks. Cross-frame scripting is a type of phishing attack that involves instructions to an unsuspecting user to follow a specific link to update confidential information in an online application. Because the link leads to a legitimate page from the online application that is embedded in a frame hosted by the attackers' server, the attackers can capture all the information that the user enters. https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Please read comments before pushing - might need a note in the Release notes. Yes, it could have worked if we didn't use iframe :) But we do! To reproduce: - modify a record in a batch (tools/batch_record_modification.pl) - click on preview marc => With this patch you will get a blank page. Good catch! Created attachment 44828 [details] [review] Bug 15111: Change X-Frame-Options with SAMEORIGIN There are some places where frames are used, the greybox JS plugin for instance. We need either to allow them from Koha or replace this plugin. The easier for now is to switch the value from DENY with SAMEORIGIN. Test plan: - modify a record in a batch (tools/batch_record_modification.pl) - click on preview marc => With only the previous patch you will get a blank page. => With this patch apply, it will work as expected. This seems still broken for greybox things, example in the label creator when you are exporting a batch, the greybox doesn't load - it performs it's fallback but I don't think that's how we want it to be. It works for the record preview because it does not include doc-head-close.inc. Created attachment 45444 [details] [review] Bug 15111: Change X-Frame-Options with SAMEORIGIN There are some places where frames are used, the greybox JS plugin for instance. We need either to allow them from Koha or replace this plugin. The easier for now is to switch the value from DENY with SAMEORIGIN. Test plan: - modify a record in a batch (tools/batch_record_modification.pl) - click on preview marc => With only the previous patch you will get a blank page. => With this patch apply, it will work as expected. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Kyle, it does not seem to work, see comment 15. (In reply to Jonathan Druart from comment #18) > Kyle, it does not seem to work, see comment 15. Ack! Missed that! Anyone have chance to finish this off? Created attachment 48265 [details] [review] Bug 15111: Do not include the antiClickjack legacy browser trick for greybox Most of the scripts called via greybox (which uses iframe) don't include doc-head-close. But some do. This patch adds a popup parameter for these templates, not to include the legacy browser trick and avoid the replacement of the location. Test plan: 1/ Export patroncard and label 2/ translate itemtypes 3/ click on a idref link at the OPAC Kyle and Jonathan - could you sign off on each other's patches maybe? Created attachment 48440 [details] [review] Bug 15111 - Koha is vulnerable to Cross-Frame Scripting (XFS) attacks Web pages that can be embedded in frames are vulnerable to cross-frame scripting attacks. Cross-frame scripting is a type of phishing attack that involves instructions to an unsuspecting user to follow a specific link to update confidential information in an online application. Because the link leads to a legitimate page from the online application that is embedded in a frame hosted by the attackers' server, the attackers can capture all the information that the user enters. https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Created attachment 48441 [details] [review] Bug 15111: Change X-Frame-Options with SAMEORIGIN There are some places where frames are used, the greybox JS plugin for instance. We need either to allow them from Koha or replace this plugin. The easier for now is to switch the value from DENY with SAMEORIGIN. Test plan: - modify a record in a batch (tools/batch_record_modification.pl) - click on preview marc => With only the previous patch you will get a blank page. => With this patch apply, it will work as expected. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Created attachment 48442 [details] [review] Bug 15111: Do not include the antiClickjack legacy browser trick for greybox Most of the scripts called via greybox (which uses iframe) don't include doc-head-close. But some do. This patch adds a popup parameter for these templates, not to include the legacy browser trick and avoid the replacement of the location. Test plan: 1/ Export patroncard and label 2/ translate itemtypes 3/ click on a idref link at the OPAC Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> This is a security bug guys... Created attachment 48646 [details] [review] Bug 15111 - Koha is vulnerable to Cross-Frame Scripting (XFS) attacks Web pages that can be embedded in frames are vulnerable to cross-frame scripting attacks. Cross-frame scripting is a type of phishing attack that involves instructions to an unsuspecting user to follow a specific link to update confidential information in an online application. Because the link leads to a legitimate page from the online application that is embedded in a frame hosted by the attackers' server, the attackers can capture all the information that the user enters. https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Created attachment 48647 [details] [review] Bug 15111: Change X-Frame-Options with SAMEORIGIN There are some places where frames are used, the greybox JS plugin for instance. We need either to allow them from Koha or replace this plugin. The easier for now is to switch the value from DENY with SAMEORIGIN. Test plan: - modify a record in a batch (tools/batch_record_modification.pl) - click on preview marc => With only the previous patch you will get a blank page. => With this patch apply, it will work as expected. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Created attachment 48648 [details] [review] Bug 15111: Do not include the antiClickjack legacy browser trick for greybox Most of the scripts called via greybox (which uses iframe) don't include doc-head-close. But some do. This patch adds a popup parameter for these templates, not to include the legacy browser trick and avoid the replacement of the location. Test plan: 1/ Export patroncard and label 2/ translate itemtypes 3/ click on a idref link at the OPAC Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Any QAers around? Skipping QA. Pushed to master! Will be in Koha 16.05! Thanks for the followups Jonathan! Well, we have a problem. After reading this https://www.owasp.org/images/0/0e/OWASP_AppSec_Research_2010_Busting_Frame_Busting_by_Rydstedt.pdf it seems that it is not possible not to be vulnerable to XFS and render something with JS disabled... Patches pushed to 3.22.x, will be in 3.22.6 |