-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TECHNICAL SUPPORT] LPS-125854 Fix XSS validating context and encoding HTML #699
Conversation
CI is automatically triggering the following test suites:
|
❌ ci:test:sf - 0 out of 1 jobs passed in 3 minutesClick here for more details.Base Branch:Branch Name: master Sender Branch:Branch Name: LPS-125854 1 Failed Jobs:For more details click here.
|
There are many SF issues in the module that is not connected to my changes. I figured we don't do sourceFormat on this file, am I right? |
Jenkins Build:test-portal-source-format#2369 |
Hi @NemethNorbert Ideally, we should upgrade to a version of jQuery Form Plugin which includes the fix. If that's not possible, at least update the version to something like 3.51.0.LIFERAY-PATCHED-ISSUE-586 so that it's a little more obvious that this file includes a patch for jQuery Form issue 586. Thanks. |
@NemethNorbert if I run It might be worth fixing those ( |
@samuelkong, the latest version is not including this fix. I will update the file based on your suggestions. @julien I give it a go and make an SF commit as well. Thanks, |
Jenkins Build:test-portal-acceptance-pullrequest(master)#7680 |
@NemethNorbert just wanted to let you know that in the I'm going to look if something has changed regarding formatting or linting in the module just to make sure we're not missing something. |
Thanks @julien for looking into that. I also run an SF on 7.2.x and I found 18errors that can be found on master as well. I think this file is not transpired and we ignored the SF errors on it so far. @samuelkong I updated the file with the suggested version change Thank you, |
@NemethNorbert I don't think it has to do with transpiling but rather linting and formatting. In LPS-100905, we added linting and formatting support for "older" modules, and it seems the original PR was this one, which seems to have been forwarded here: in that PR I don't see any CI errors concerning formatting or linting - I'm going to keep on searching |
@NemethNorbert what's interesting is that the |
Hey @julien I mentioned transpiling as our SF rules forces arrow functions on master, that would be a no go in this case. About the ignore files, that's indeed interesting. At least we know we intended to ignore these files when it comes to linting or formatting |
@NemethNorbert my bad, I got it all wrong. If you run What I did was run diff --git a/modules/apps/frontend-js/frontend-js-jquery-web/src/main/resources/META-INF/resources/jquery/form.js b/modules/apps/frontend-js/frontend-js-jquery-web/src/main/resources/META-INF/resources/jquery/form.js
index 9d9844c52fa6..823d3aa40915 100644
--- a/modules/apps/frontend-js/frontend-js-jquery-web/src/main/resources/META-INF/resources/jquery/form.js
+++ b/modules/apps/frontend-js/frontend-js-jquery-web/src/main/resources/META-INF/resources/jquery/form.js
@@ -244,9 +244,12 @@
callbacks.push(function (data) {
var fn = options.replaceTarget ? 'replaceWith' : 'html';
- // Validate `data` through `HTML encoding` when passed `data` is passed
- // to `html()`, as suggested in https://github.com/jquery-form/form/issues/464
- fn == 'html' ? data = $.parseHTML($("<div>").text(data).html()) : '';
+ // Validate `data` through `HTML encoding` when passed `data` is passed
+ // to `html()`, as suggested in https://github.com/jquery-form/form/issues/464
+
+ fn == 'html'
+ ? (data = $.parseHTML($('<div>').text(data).html()))
+ : '';
$(options.target)[fn](data).each(oldSuccess, arguments);
});
@@ -1082,7 +1085,7 @@
$.parseJSON ||
function (s) {
- // Arise an error resolvable including jquery instead of
+ // Arise an error resolvable including jquery instead of
// making a new function using unsanitized inputs
window.console.error('jquery.parseJSON is undefined');
So if you do that, commit the change and push, the SF tests should pass |
Thanks @julien I pushed the SF commit :) |
ci:test:sf |
All required test suite(s) passed. |
Pull request has been successfully forwarded to brianchandotcom#97915 |
Jenkins Build:test-portal-acceptance-pullrequest(master)#6591 |
Reopening based on Brian's comment
@NemethNorbert, thinking about it, we don't even add We will still need to figure out a way to patch it in other branches. I'm not even sure this is actually safe to do based on the Copyright header. Maybe we shouldn't be hosting this at all! Could you please open an inbound licensing JIRA issue so this can be evaluated? |
@jbalsas , could you open this licensing ticket and follow up on this? I don't know what type of ticket you are talking about neither what would be the problem I should describe there. Thank you |
Hey @NemethNorbert, for external code (3rd party) we should usually file an "Inbound License" type of issue in our "INTERNAL - FOSS Licensing Issues" in JIRA to make sure that including the source code is compatible with our license. I was worried because I didn't see that it's actually dual licensed as MIT-GPL
I think that means it's okay. As I said, I think we should simply get rid of this library in In If we want to do a quick fix for older versions, I would indeed suggest that we either go the patch route that Brian suggests or absorb the code (if possible). I would ask Legal again to see if this is okay or not. |
Hey @jbalsas , I intend to backport this security fix till 7.1. As this issue is a reported security vulnerability, I don't think we can wait for the above mentioned fix to be merged and released (its already sitting there for more than 6months now, while the fix itself is accepted). In that case we would also be looking forward to upgrade our jQuery form.js to the latest version that might present its own set of problems. I would like to do a quick fix for older versions, could you create a solution for me with the recommended patch route? I don't even know where to start with that. I would take care of all the necessary backports after that. |
Hey @NemethNorbert, we can look at it, but it will take some time since we're pressed on other fronts at the moment. |
I really appreciate it @jbalsas Thank you for your help |
hey @liferay-frontend, Thanks, |
@NemethNorbert: I pinged some folks on a thread in the team Slack (private link, but including it here for those who can read it anyway) to get some opinions on whether the draft PR is the best approach (or at least an adequate one); will let you know once we reach a conclusion. |
@NemethNorbert: We concluded that we're just going to fork the project into our monorepo and patch it there. I'm going to do that today, so closing this one for now; I created an issue in the monorepo for you or anybody else who is interested to have something they can subscribe to to track progress on this one. |
See: #772 |
@NemethNorbert — Upstream PR got merged: brianchandotcom#98619 Of course, I put the wrong LPS in the commit subject line and PR title (LPS-125853 instead of LPS-125854), just to make traceability interesting 🤦♂️... |
Hey,
LPS-125854,
I based my work on: 418sec/form#1
First sec issue, let me know if I missed something.
Please review it.
Thanks,