From dominique.righetto at gmail.com Wed Oct 28 10:03:29 2015 From: dominique.righetto at gmail.com (Dominique Righetto) Date: Wed, 28 Oct 2015 11:03:29 +0100 Subject: [Owasp_sonarqube] New rule spec proposal for JavaScript Message-ID: Hello, I send you this mail in order to propose a new rule spec for JavaScript. It's about HTML5 Cross Document Messaging feature [1] For exchange messages, the window.postMessage(message, targetOrigin) function is used and the target origin is specified in the second parameter after the message content. As it's specified into the specification (section 4.2.1): "Authors should not use the wildcard keyword (*) in the targetOrigin argument in messages that contain any confidential information, as otherwise there is no way to guarantee that the message is only delivered to the recipient to which it was intended." It can be interesting to add a new rule to detect use of "*" keyword into target origin parameter in case of use of Cross Document Messaging feature. Spotted code: var o = document.getElementsByTagName('iframe')[0]; o.contentWindow.postMessage("Confidential message", "*"); Valid code: var o = document.getElementsByTagName('iframe')[0]; o.contentWindow.postMessage("Confidential message", " http://sender-domain.com"); What do you think ? [1] http://www.w3.org/TR/2011/WD-webmessaging-20110317/ Thanks in advance. -- Cordialement, Best regards, Dominique Righetto dominique.righetto at gmail.com GPG: 323D19BA -------------- next part -------------- An HTML attachment was scrubbed... URL: From ann.campbell at sonarsource.com Wed Oct 28 10:57:54 2015 From: ann.campbell at sonarsource.com (G. Ann Campbell) Date: Wed, 28 Oct 2015 06:57:54 -0400 Subject: [Owasp_sonarqube] New rule spec proposal for JavaScript In-Reply-To: References: Message-ID: Beat you to it! :-) 1. RSPEC-2819 Cross-document messaging domains should be carefully restricted --- *G. Ann CAMPBELL* | SonarSource Product Owner http://sonarsource.com On Wed, Oct 28, 2015 at 6:03 AM, Dominique Righetto < dominique.righetto at gmail.com> wrote: > Hello, > > I send you this mail in order to propose a new rule spec for JavaScript. > > It's about HTML5 Cross Document Messaging feature [1] > > For exchange messages, the window.postMessage(message, targetOrigin) > function is used and the target origin is specified in the second parameter > after the message content. > > As it's specified into the specification (section 4.2.1): > > "Authors should not use the wildcard keyword (*) in the targetOrigin > argument in messages that contain any confidential information, as > otherwise there is no way to guarantee that the message is only delivered > to the recipient to which it was intended." > > It can be interesting to add a new rule to detect use of "*" keyword into > target origin parameter in case of use of Cross Document Messaging feature. > > Spotted code: > var o = document.getElementsByTagName('iframe')[0]; > o.contentWindow.postMessage("Confidential message", "*"); > > Valid code: > var o = document.getElementsByTagName('iframe')[0]; > o.contentWindow.postMessage("Confidential message", " > http://sender-domain.com"); > > What do you think ? > > [1] http://www.w3.org/TR/2011/WD-webmessaging-20110317/ > > Thanks in advance. > -- > Cordialement, Best regards, > Dominique Righetto > dominique.righetto at gmail.com > GPG: 323D19BA > > _______________________________________________ > Owasp_sonarqube mailing list > Owasp_sonarqube at lists.owasp.org > https://lists.owasp.org/mailman/listinfo/owasp_sonarqube > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominique.righetto at gmail.com Wed Oct 28 11:07:06 2015 From: dominique.righetto at gmail.com (Dominique Righetto) Date: Wed, 28 Oct 2015 12:07:06 +0100 Subject: [Owasp_sonarqube] New rule spec proposal for JavaScript In-Reply-To: References: Message-ID: Thanks for the ref :) Is it possible to enhance the description and code samples with infos that I have provided ? What do you think ? -- Cordialement, Best regards, Dominique Righetto dominique.righetto at gmail.com GPG: 323D19BA On Wed, Oct 28, 2015 at 11:57 AM, G. Ann Campbell < ann.campbell at sonarsource.com> wrote: > Beat you to it! :-) > > > 1. RSPEC-2819 Cross-document > messaging domains should be carefully restricted > > > > > --- > *G. Ann CAMPBELL* | SonarSource > Product Owner > http://sonarsource.com > > On Wed, Oct 28, 2015 at 6:03 AM, Dominique Righetto < > dominique.righetto at gmail.com> wrote: > >> Hello, >> >> I send you this mail in order to propose a new rule spec for JavaScript. >> >> It's about HTML5 Cross Document Messaging feature [1] >> >> For exchange messages, the window.postMessage(message, targetOrigin) >> function is used and the target origin is specified in the second parameter >> after the message content. >> >> As it's specified into the specification (section 4.2.1): >> >> "Authors should not use the wildcard keyword (*) in the targetOrigin >> argument in messages that contain any confidential information, as >> otherwise there is no way to guarantee that the message is only delivered >> to the recipient to which it was intended." >> >> It can be interesting to add a new rule to detect use of "*" keyword into >> target origin parameter in case of use of Cross Document Messaging feature. >> >> Spotted code: >> var o = document.getElementsByTagName('iframe')[0]; >> o.contentWindow.postMessage("Confidential message", "*"); >> >> Valid code: >> var o = document.getElementsByTagName('iframe')[0]; >> o.contentWindow.postMessage("Confidential message", " >> http://sender-domain.com"); >> >> What do you think ? >> >> [1] http://www.w3.org/TR/2011/WD-webmessaging-20110317/ >> >> Thanks in advance. >> -- >> Cordialement, Best regards, >> Dominique Righetto >> dominique.righetto at gmail.com >> GPG: 323D19BA >> >> _______________________________________________ >> Owasp_sonarqube mailing list >> Owasp_sonarqube at lists.owasp.org >> https://lists.owasp.org/mailman/listinfo/owasp_sonarqube >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ann.campbell at sonarsource.com Wed Oct 28 11:20:30 2015 From: ann.campbell at sonarsource.com (G. Ann Campbell) Date: Wed, 28 Oct 2015 07:20:30 -0400 Subject: [Owasp_sonarqube] New rule spec proposal for JavaScript In-Reply-To: References: Message-ID: Well, your noncompliant code sample is basically the same as mine, and I can't use your compliant solution because the rule raises an issue whenever window.postMessage is used. But I did add your specification quote. BTW, this is already implemented . --- *G. Ann CAMPBELL* | SonarSource Product Owner http://sonarsource.com On Wed, Oct 28, 2015 at 7:07 AM, Dominique Righetto < dominique.righetto at gmail.com> wrote: > Thanks for the ref :) > > Is it possible to enhance the description and code samples with infos that > I have provided ? > > What do you think ? > > -- > Cordialement, Best regards, > Dominique Righetto > dominique.righetto at gmail.com > GPG: 323D19BA > > On Wed, Oct 28, 2015 at 11:57 AM, G. Ann Campbell < > ann.campbell at sonarsource.com> wrote: > >> Beat you to it! :-) >> >> >> 1. RSPEC-2819 Cross-document >> messaging domains should be carefully restricted >> >> >> >> >> --- >> *G. Ann CAMPBELL* | SonarSource >> Product Owner >> http://sonarsource.com >> >> On Wed, Oct 28, 2015 at 6:03 AM, Dominique Righetto < >> dominique.righetto at gmail.com> wrote: >> >>> Hello, >>> >>> I send you this mail in order to propose a new rule spec for JavaScript. >>> >>> It's about HTML5 Cross Document Messaging feature [1] >>> >>> For exchange messages, the window.postMessage(message, targetOrigin) >>> function is used and the target origin is specified in the second parameter >>> after the message content. >>> >>> As it's specified into the specification (section 4.2.1): >>> >>> "Authors should not use the wildcard keyword (*) in the targetOrigin >>> argument in messages that contain any confidential information, as >>> otherwise there is no way to guarantee that the message is only delivered >>> to the recipient to which it was intended." >>> >>> It can be interesting to add a new rule to detect use of "*" keyword >>> into target origin parameter in case of use of Cross Document Messaging >>> feature. >>> >>> Spotted code: >>> var o = document.getElementsByTagName('iframe')[0]; >>> o.contentWindow.postMessage("Confidential message", "*"); >>> >>> Valid code: >>> var o = document.getElementsByTagName('iframe')[0]; >>> o.contentWindow.postMessage("Confidential message", " >>> http://sender-domain.com"); >>> >>> What do you think ? >>> >>> [1] http://www.w3.org/TR/2011/WD-webmessaging-20110317/ >>> >>> Thanks in advance. >>> -- >>> Cordialement, Best regards, >>> Dominique Righetto >>> dominique.righetto at gmail.com >>> GPG: 323D19BA >>> >>> _______________________________________________ >>> Owasp_sonarqube mailing list >>> Owasp_sonarqube at lists.owasp.org >>> https://lists.owasp.org/mailman/listinfo/owasp_sonarqube >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominique.righetto at gmail.com Wed Oct 28 11:35:51 2015 From: dominique.righetto at gmail.com (Dominique Righetto) Date: Wed, 28 Oct 2015 12:35:51 +0100 Subject: [Owasp_sonarqube] New rule spec proposal for JavaScript In-Reply-To: References: Message-ID: Raising an issue whenever window.postMessage is used, is for my personal opinion, not a good way because it will cause a false-positive if the use of the method is correct like in the compliant code sample...The implication is that rule will be disabled by dev team if it cause false-positive. I see that the resolution status is "unresolved" is it normal if the rule is implemented ? Thanks for the quote :) -- Cordialement, Best regards, Dominique Righetto dominique.righetto at gmail.com GPG: 323D19BA On Wed, Oct 28, 2015 at 12:20 PM, G. Ann Campbell < ann.campbell at sonarsource.com> wrote: > Well, your noncompliant code sample is basically the same as mine, and I > can't use your compliant solution because the rule raises an issue whenever > window.postMessage is used. But I did add your specification quote. > > BTW, this is already implemented > . > > > > --- > *G. Ann CAMPBELL* | SonarSource > Product Owner > http://sonarsource.com > > On Wed, Oct 28, 2015 at 7:07 AM, Dominique Righetto < > dominique.righetto at gmail.com> wrote: > >> Thanks for the ref :) >> >> Is it possible to enhance the description and code samples with infos >> that I have provided ? >> >> What do you think ? >> >> -- >> Cordialement, Best regards, >> Dominique Righetto >> dominique.righetto at gmail.com >> GPG: 323D19BA >> >> On Wed, Oct 28, 2015 at 11:57 AM, G. Ann Campbell < >> ann.campbell at sonarsource.com> wrote: >> >>> Beat you to it! :-) >>> >>> >>> 1. RSPEC-2819 Cross-document >>> messaging domains should be carefully restricted >>> >>> >>> >>> >>> --- >>> *G. Ann CAMPBELL* | SonarSource >>> Product Owner >>> http://sonarsource.com >>> >>> On Wed, Oct 28, 2015 at 6:03 AM, Dominique Righetto < >>> dominique.righetto at gmail.com> wrote: >>> >>>> Hello, >>>> >>>> I send you this mail in order to propose a new rule spec for JavaScript. >>>> >>>> It's about HTML5 Cross Document Messaging feature [1] >>>> >>>> For exchange messages, the window.postMessage(message, targetOrigin) >>>> function is used and the target origin is specified in the second parameter >>>> after the message content. >>>> >>>> As it's specified into the specification (section 4.2.1): >>>> >>>> "Authors should not use the wildcard keyword (*) in the targetOrigin >>>> argument in messages that contain any confidential information, as >>>> otherwise there is no way to guarantee that the message is only delivered >>>> to the recipient to which it was intended." >>>> >>>> It can be interesting to add a new rule to detect use of "*" keyword >>>> into target origin parameter in case of use of Cross Document Messaging >>>> feature. >>>> >>>> Spotted code: >>>> var o = document.getElementsByTagName('iframe')[0]; >>>> o.contentWindow.postMessage("Confidential message", "*"); >>>> >>>> Valid code: >>>> var o = document.getElementsByTagName('iframe')[0]; >>>> o.contentWindow.postMessage("Confidential message", " >>>> http://sender-domain.com"); >>>> >>>> What do you think ? >>>> >>>> [1] http://www.w3.org/TR/2011/WD-webmessaging-20110317/ >>>> >>>> Thanks in advance. >>>> -- >>>> Cordialement, Best regards, >>>> Dominique Righetto >>>> dominique.righetto at gmail.com >>>> GPG: 323D19BA >>>> >>>> _______________________________________________ >>>> Owasp_sonarqube mailing list >>>> Owasp_sonarqube at lists.owasp.org >>>> https://lists.owasp.org/mailman/listinfo/owasp_sonarqube >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominique.righetto at gmail.com Wed Oct 28 12:36:56 2015 From: dominique.righetto at gmail.com (Dominique Righetto) Date: Wed, 28 Oct 2015 13:36:56 +0100 Subject: [Owasp_sonarqube] New rule spec proposal for JavaScript In-Reply-To: References: Message-ID: In the same way, do you think that SonarQube rule engine will be able to detect (if I propose a dedicated rule spec) the non validation of the event sender (origin) in the message handler on receiver side ? Example of handler code on receiver side: window.addEventListener('message', receiver); function receiver(e) { var msg = "Received message from Origin '" + e.origin + "' => '" + e.data + "'"; //do stuff... } Thanks in advance :) -- Cordialement, Best regards, Dominique Righetto dominique.righetto at gmail.com GPG: 323D19BA On Wed, Oct 28, 2015 at 12:35 PM, Dominique Righetto < dominique.righetto at gmail.com> wrote: > Raising an issue whenever window.postMessage is used, is for my personal > opinion, not a good way because it will cause a false-positive if the use > of the method is correct like in the compliant code sample...The > implication is that rule will be disabled by dev team if it cause > false-positive. > > I see that the resolution status is "unresolved" is it normal if the rule > is implemented ? > > Thanks for the quote :) > > -- > Cordialement, Best regards, > Dominique Righetto > dominique.righetto at gmail.com > GPG: 323D19BA > > On Wed, Oct 28, 2015 at 12:20 PM, G. Ann Campbell < > ann.campbell at sonarsource.com> wrote: > >> Well, your noncompliant code sample is basically the same as mine, and I >> can't use your compliant solution because the rule raises an issue whenever >> window.postMessage is used. But I did add your specification quote. >> >> BTW, this is already implemented >> . >> >> >> >> --- >> *G. Ann CAMPBELL* | SonarSource >> Product Owner >> http://sonarsource.com >> >> On Wed, Oct 28, 2015 at 7:07 AM, Dominique Righetto < >> dominique.righetto at gmail.com> wrote: >> >>> Thanks for the ref :) >>> >>> Is it possible to enhance the description and code samples with infos >>> that I have provided ? >>> >>> What do you think ? >>> >>> -- >>> Cordialement, Best regards, >>> Dominique Righetto >>> dominique.righetto at gmail.com >>> GPG: 323D19BA >>> >>> On Wed, Oct 28, 2015 at 11:57 AM, G. Ann Campbell < >>> ann.campbell at sonarsource.com> wrote: >>> >>>> Beat you to it! :-) >>>> >>>> >>>> 1. RSPEC-2819 Cross-document >>>> messaging domains should be carefully restricted >>>> >>>> >>>> >>>> >>>> --- >>>> *G. Ann CAMPBELL* | SonarSource >>>> Product Owner >>>> http://sonarsource.com >>>> >>>> On Wed, Oct 28, 2015 at 6:03 AM, Dominique Righetto < >>>> dominique.righetto at gmail.com> wrote: >>>> >>>>> Hello, >>>>> >>>>> I send you this mail in order to propose a new rule spec for >>>>> JavaScript. >>>>> >>>>> It's about HTML5 Cross Document Messaging feature [1] >>>>> >>>>> For exchange messages, the window.postMessage(message, targetOrigin) >>>>> function is used and the target origin is specified in the second parameter >>>>> after the message content. >>>>> >>>>> As it's specified into the specification (section 4.2.1): >>>>> >>>>> "Authors should not use the wildcard keyword (*) in the targetOrigin >>>>> argument in messages that contain any confidential information, as >>>>> otherwise there is no way to guarantee that the message is only delivered >>>>> to the recipient to which it was intended." >>>>> >>>>> It can be interesting to add a new rule to detect use of "*" keyword >>>>> into target origin parameter in case of use of Cross Document Messaging >>>>> feature. >>>>> >>>>> Spotted code: >>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>> o.contentWindow.postMessage("Confidential message", "*"); >>>>> >>>>> Valid code: >>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>> o.contentWindow.postMessage("Confidential message", " >>>>> http://sender-domain.com"); >>>>> >>>>> What do you think ? >>>>> >>>>> [1] http://www.w3.org/TR/2011/WD-webmessaging-20110317/ >>>>> >>>>> Thanks in advance. >>>>> -- >>>>> Cordialement, Best regards, >>>>> Dominique Righetto >>>>> dominique.righetto at gmail.com >>>>> GPG: 323D19BA >>>>> >>>>> _______________________________________________ >>>>> Owasp_sonarqube mailing list >>>>> Owasp_sonarqube at lists.owasp.org >>>>> https://lists.owasp.org/mailman/listinfo/owasp_sonarqube >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ann.campbell at sonarsource.com Wed Oct 28 12:42:05 2015 From: ann.campbell at sonarsource.com (G. Ann Campbell) Date: Wed, 28 Oct 2015 08:42:05 -0400 Subject: [Owasp_sonarqube] New rule spec proposal for JavaScript In-Reply-To: References: Message-ID: If I'm understanding correctly @Dominique, it would be extremely difficult: what does a proper validation look like? And what if it's handed off to another function? A function in another file? We would only reliably be able to flag uses of origin, and say something like "make sure this message is from a trusted source". --- *G. Ann CAMPBELL* | SonarSource Product Owner http://sonarsource.com On Wed, Oct 28, 2015 at 8:36 AM, Dominique Righetto < dominique.righetto at gmail.com> wrote: > In the same way, do you think that SonarQube rule engine will be able to > detect (if I propose a dedicated rule spec) the non validation of the event > sender (origin) in the message handler on receiver side ? > > Example of handler code on receiver side: > window.addEventListener('message', receiver); > function receiver(e) { > var msg = "Received message from Origin '" + e.origin + "' => '" + > e.data + "'"; > //do stuff... > } > > Thanks in advance :) > > > -- > Cordialement, Best regards, > Dominique Righetto > dominique.righetto at gmail.com > GPG: 323D19BA > > On Wed, Oct 28, 2015 at 12:35 PM, Dominique Righetto < > dominique.righetto at gmail.com> wrote: > >> Raising an issue whenever window.postMessage is used, is for my personal >> opinion, not a good way because it will cause a false-positive if the use >> of the method is correct like in the compliant code sample...The >> implication is that rule will be disabled by dev team if it cause >> false-positive. >> >> I see that the resolution status is "unresolved" is it normal if the rule >> is implemented ? >> >> Thanks for the quote :) >> >> -- >> Cordialement, Best regards, >> Dominique Righetto >> dominique.righetto at gmail.com >> GPG: 323D19BA >> >> On Wed, Oct 28, 2015 at 12:20 PM, G. Ann Campbell < >> ann.campbell at sonarsource.com> wrote: >> >>> Well, your noncompliant code sample is basically the same as mine, and I >>> can't use your compliant solution because the rule raises an issue whenever >>> window.postMessage is used. But I did add your specification quote. >>> >>> BTW, this is already implemented >>> . >>> >>> >>> >>> --- >>> *G. Ann CAMPBELL* | SonarSource >>> Product Owner >>> http://sonarsource.com >>> >>> On Wed, Oct 28, 2015 at 7:07 AM, Dominique Righetto < >>> dominique.righetto at gmail.com> wrote: >>> >>>> Thanks for the ref :) >>>> >>>> Is it possible to enhance the description and code samples with infos >>>> that I have provided ? >>>> >>>> What do you think ? >>>> >>>> -- >>>> Cordialement, Best regards, >>>> Dominique Righetto >>>> dominique.righetto at gmail.com >>>> GPG: 323D19BA >>>> >>>> On Wed, Oct 28, 2015 at 11:57 AM, G. Ann Campbell < >>>> ann.campbell at sonarsource.com> wrote: >>>> >>>>> Beat you to it! :-) >>>>> >>>>> >>>>> 1. RSPEC-2819 Cross-document >>>>> messaging domains should be carefully restricted >>>>> >>>>> >>>>> >>>>> >>>>> --- >>>>> *G. Ann CAMPBELL* | SonarSource >>>>> Product Owner >>>>> http://sonarsource.com >>>>> >>>>> On Wed, Oct 28, 2015 at 6:03 AM, Dominique Righetto < >>>>> dominique.righetto at gmail.com> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I send you this mail in order to propose a new rule spec for >>>>>> JavaScript. >>>>>> >>>>>> It's about HTML5 Cross Document Messaging feature [1] >>>>>> >>>>>> For exchange messages, the window.postMessage(message, targetOrigin) >>>>>> function is used and the target origin is specified in the second parameter >>>>>> after the message content. >>>>>> >>>>>> As it's specified into the specification (section 4.2.1): >>>>>> >>>>>> "Authors should not use the wildcard keyword (*) in the targetOrigin >>>>>> argument in messages that contain any confidential information, as >>>>>> otherwise there is no way to guarantee that the message is only delivered >>>>>> to the recipient to which it was intended." >>>>>> >>>>>> It can be interesting to add a new rule to detect use of "*" keyword >>>>>> into target origin parameter in case of use of Cross Document Messaging >>>>>> feature. >>>>>> >>>>>> Spotted code: >>>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>>> o.contentWindow.postMessage("Confidential message", "*"); >>>>>> >>>>>> Valid code: >>>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>>> o.contentWindow.postMessage("Confidential message", " >>>>>> http://sender-domain.com"); >>>>>> >>>>>> What do you think ? >>>>>> >>>>>> [1] http://www.w3.org/TR/2011/WD-webmessaging-20110317/ >>>>>> >>>>>> Thanks in advance. >>>>>> -- >>>>>> Cordialement, Best regards, >>>>>> Dominique Righetto >>>>>> dominique.righetto at gmail.com >>>>>> GPG: 323D19BA >>>>>> >>>>>> _______________________________________________ >>>>>> Owasp_sonarqube mailing list >>>>>> Owasp_sonarqube at lists.owasp.org >>>>>> https://lists.owasp.org/mailman/listinfo/owasp_sonarqube >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominique.righetto at gmail.com Wed Oct 28 14:26:57 2015 From: dominique.righetto at gmail.com (Dominique Righetto) Date: Wed, 28 Oct 2015 15:26:57 +0100 Subject: [Owasp_sonarqube] New rule spec proposal for JavaScript In-Reply-To: References: Message-ID: Thanks for your response :) A correct use of "origin" should be to perform a comparison of the "origin" attribute value coming from the event against a value. Ex: function receiver(e) { if(e.origin == "XXX"){ //do stuff } } We can check if the "origin" parameter is used in the function associated to the "message" event type. What do you think ? -- Cordialement, Best regards, Dominique Righetto dominique.righetto at gmail.com GPG: 323D19BA On Wed, Oct 28, 2015 at 1:42 PM, G. Ann Campbell < ann.campbell at sonarsource.com> wrote: > If I'm understanding correctly @Dominique, it would be extremely > difficult: what does a proper validation look like? And what if it's handed > off to another function? A function in another file? > > We would only reliably be able to flag uses of origin, and say something > like "make sure this message is from a trusted source". > > > > --- > *G. Ann CAMPBELL* | SonarSource > Product Owner > http://sonarsource.com > > On Wed, Oct 28, 2015 at 8:36 AM, Dominique Righetto < > dominique.righetto at gmail.com> wrote: > >> In the same way, do you think that SonarQube rule engine will be able to >> detect (if I propose a dedicated rule spec) the non validation of the event >> sender (origin) in the message handler on receiver side ? >> >> Example of handler code on receiver side: >> window.addEventListener('message', receiver); >> function receiver(e) { >> var msg = "Received message from Origin '" + e.origin + "' => '" + >> e.data + "'"; >> //do stuff... >> } >> >> Thanks in advance :) >> >> >> -- >> Cordialement, Best regards, >> Dominique Righetto >> dominique.righetto at gmail.com >> GPG: 323D19BA >> >> On Wed, Oct 28, 2015 at 12:35 PM, Dominique Righetto < >> dominique.righetto at gmail.com> wrote: >> >>> Raising an issue whenever window.postMessage is used, is for my personal >>> opinion, not a good way because it will cause a false-positive if the use >>> of the method is correct like in the compliant code sample...The >>> implication is that rule will be disabled by dev team if it cause >>> false-positive. >>> >>> I see that the resolution status is "unresolved" is it normal if the >>> rule is implemented ? >>> >>> Thanks for the quote :) >>> >>> -- >>> Cordialement, Best regards, >>> Dominique Righetto >>> dominique.righetto at gmail.com >>> GPG: 323D19BA >>> >>> On Wed, Oct 28, 2015 at 12:20 PM, G. Ann Campbell < >>> ann.campbell at sonarsource.com> wrote: >>> >>>> Well, your noncompliant code sample is basically the same as mine, and >>>> I can't use your compliant solution because the rule raises an issue >>>> whenever window.postMessage is used. But I did add your specification quote. >>>> >>>> BTW, this is already implemented >>>> . >>>> >>>> >>>> >>>> --- >>>> *G. Ann CAMPBELL* | SonarSource >>>> Product Owner >>>> http://sonarsource.com >>>> >>>> On Wed, Oct 28, 2015 at 7:07 AM, Dominique Righetto < >>>> dominique.righetto at gmail.com> wrote: >>>> >>>>> Thanks for the ref :) >>>>> >>>>> Is it possible to enhance the description and code samples with infos >>>>> that I have provided ? >>>>> >>>>> What do you think ? >>>>> >>>>> -- >>>>> Cordialement, Best regards, >>>>> Dominique Righetto >>>>> dominique.righetto at gmail.com >>>>> GPG: 323D19BA >>>>> >>>>> On Wed, Oct 28, 2015 at 11:57 AM, G. Ann Campbell < >>>>> ann.campbell at sonarsource.com> wrote: >>>>> >>>>>> Beat you to it! :-) >>>>>> >>>>>> >>>>>> 1. RSPEC-2819 Cross-document >>>>>> messaging domains should be carefully restricted >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> --- >>>>>> *G. Ann CAMPBELL* | SonarSource >>>>>> Product Owner >>>>>> http://sonarsource.com >>>>>> >>>>>> On Wed, Oct 28, 2015 at 6:03 AM, Dominique Righetto < >>>>>> dominique.righetto at gmail.com> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I send you this mail in order to propose a new rule spec for >>>>>>> JavaScript. >>>>>>> >>>>>>> It's about HTML5 Cross Document Messaging feature [1] >>>>>>> >>>>>>> For exchange messages, the window.postMessage(message, targetOrigin) >>>>>>> function is used and the target origin is specified in the second parameter >>>>>>> after the message content. >>>>>>> >>>>>>> As it's specified into the specification (section 4.2.1): >>>>>>> >>>>>>> "Authors should not use the wildcard keyword (*) in the targetOrigin >>>>>>> argument in messages that contain any confidential information, as >>>>>>> otherwise there is no way to guarantee that the message is only delivered >>>>>>> to the recipient to which it was intended." >>>>>>> >>>>>>> It can be interesting to add a new rule to detect use of "*" keyword >>>>>>> into target origin parameter in case of use of Cross Document Messaging >>>>>>> feature. >>>>>>> >>>>>>> Spotted code: >>>>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>>>> o.contentWindow.postMessage("Confidential message", "*"); >>>>>>> >>>>>>> Valid code: >>>>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>>>> o.contentWindow.postMessage("Confidential message", " >>>>>>> http://sender-domain.com"); >>>>>>> >>>>>>> What do you think ? >>>>>>> >>>>>>> [1] http://www.w3.org/TR/2011/WD-webmessaging-20110317/ >>>>>>> >>>>>>> Thanks in advance. >>>>>>> -- >>>>>>> Cordialement, Best regards, >>>>>>> Dominique Righetto >>>>>>> dominique.righetto at gmail.com >>>>>>> GPG: 323D19BA >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Owasp_sonarqube mailing list >>>>>>> Owasp_sonarqube at lists.owasp.org >>>>>>> https://lists.owasp.org/mailman/listinfo/owasp_sonarqube >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ann.campbell at sonarsource.com Wed Oct 28 14:34:28 2015 From: ann.campbell at sonarsource.com (G. Ann Campbell) Date: Wed, 28 Oct 2015 10:34:28 -0400 Subject: [Owasp_sonarqube] New rule spec proposal for JavaScript In-Reply-To: References: Message-ID: >From a coder's point of view, it seems like a regex would be a sufficient check. But from our point of view, we'd never be able to know if the regex was "good" for that situation. --- *G. Ann CAMPBELL* | SonarSource Product Owner http://sonarsource.com On Wed, Oct 28, 2015 at 10:26 AM, Dominique Righetto < dominique.righetto at gmail.com> wrote: > Thanks for your response :) > > A correct use of "origin" should be to perform a comparison of the > "origin" attribute value coming from the event against a value. > > Ex: > function receiver(e) { > if(e.origin == "XXX"){ > //do stuff > } > } > > We can check if the "origin" parameter is used in the function associated > to the "message" event type. > > What do you think ? > > -- > Cordialement, Best regards, > Dominique Righetto > dominique.righetto at gmail.com > GPG: 323D19BA > > On Wed, Oct 28, 2015 at 1:42 PM, G. Ann Campbell < > ann.campbell at sonarsource.com> wrote: > >> If I'm understanding correctly @Dominique, it would be extremely >> difficult: what does a proper validation look like? And what if it's handed >> off to another function? A function in another file? >> >> We would only reliably be able to flag uses of origin, and say something >> like "make sure this message is from a trusted source". >> >> >> >> --- >> *G. Ann CAMPBELL* | SonarSource >> Product Owner >> http://sonarsource.com >> >> On Wed, Oct 28, 2015 at 8:36 AM, Dominique Righetto < >> dominique.righetto at gmail.com> wrote: >> >>> In the same way, do you think that SonarQube rule engine will be able to >>> detect (if I propose a dedicated rule spec) the non validation of the event >>> sender (origin) in the message handler on receiver side ? >>> >>> Example of handler code on receiver side: >>> window.addEventListener('message', receiver); >>> function receiver(e) { >>> var msg = "Received message from Origin '" + e.origin + "' => '" + >>> e.data + "'"; >>> //do stuff... >>> } >>> >>> Thanks in advance :) >>> >>> >>> -- >>> Cordialement, Best regards, >>> Dominique Righetto >>> dominique.righetto at gmail.com >>> GPG: 323D19BA >>> >>> On Wed, Oct 28, 2015 at 12:35 PM, Dominique Righetto < >>> dominique.righetto at gmail.com> wrote: >>> >>>> Raising an issue whenever window.postMessage is used, is for my >>>> personal opinion, not a good way because it will cause a false-positive if >>>> the use of the method is correct like in the compliant code sample...The >>>> implication is that rule will be disabled by dev team if it cause >>>> false-positive. >>>> >>>> I see that the resolution status is "unresolved" is it normal if the >>>> rule is implemented ? >>>> >>>> Thanks for the quote :) >>>> >>>> -- >>>> Cordialement, Best regards, >>>> Dominique Righetto >>>> dominique.righetto at gmail.com >>>> GPG: 323D19BA >>>> >>>> On Wed, Oct 28, 2015 at 12:20 PM, G. Ann Campbell < >>>> ann.campbell at sonarsource.com> wrote: >>>> >>>>> Well, your noncompliant code sample is basically the same as mine, and >>>>> I can't use your compliant solution because the rule raises an issue >>>>> whenever window.postMessage is used. But I did add your specification quote. >>>>> >>>>> BTW, this is already implemented >>>>> . >>>>> >>>>> >>>>> >>>>> --- >>>>> *G. Ann CAMPBELL* | SonarSource >>>>> Product Owner >>>>> http://sonarsource.com >>>>> >>>>> On Wed, Oct 28, 2015 at 7:07 AM, Dominique Righetto < >>>>> dominique.righetto at gmail.com> wrote: >>>>> >>>>>> Thanks for the ref :) >>>>>> >>>>>> Is it possible to enhance the description and code samples with infos >>>>>> that I have provided ? >>>>>> >>>>>> What do you think ? >>>>>> >>>>>> -- >>>>>> Cordialement, Best regards, >>>>>> Dominique Righetto >>>>>> dominique.righetto at gmail.com >>>>>> GPG: 323D19BA >>>>>> >>>>>> On Wed, Oct 28, 2015 at 11:57 AM, G. Ann Campbell < >>>>>> ann.campbell at sonarsource.com> wrote: >>>>>> >>>>>>> Beat you to it! :-) >>>>>>> >>>>>>> >>>>>>> 1. RSPEC-2819 Cross-document >>>>>>> messaging domains should be carefully restricted >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --- >>>>>>> *G. Ann CAMPBELL* | SonarSource >>>>>>> Product Owner >>>>>>> http://sonarsource.com >>>>>>> >>>>>>> On Wed, Oct 28, 2015 at 6:03 AM, Dominique Righetto < >>>>>>> dominique.righetto at gmail.com> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I send you this mail in order to propose a new rule spec for >>>>>>>> JavaScript. >>>>>>>> >>>>>>>> It's about HTML5 Cross Document Messaging feature [1] >>>>>>>> >>>>>>>> For exchange messages, the window.postMessage(message, >>>>>>>> targetOrigin) function is used and the target origin is specified in the >>>>>>>> second parameter after the message content. >>>>>>>> >>>>>>>> As it's specified into the specification (section 4.2.1): >>>>>>>> >>>>>>>> "Authors should not use the wildcard keyword (*) in the >>>>>>>> targetOrigin argument in messages that contain any confidential >>>>>>>> information, as otherwise there is no way to guarantee that the message is >>>>>>>> only delivered to the recipient to which it was intended." >>>>>>>> >>>>>>>> It can be interesting to add a new rule to detect use of "*" >>>>>>>> keyword into target origin parameter in case of use of Cross Document >>>>>>>> Messaging feature. >>>>>>>> >>>>>>>> Spotted code: >>>>>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>>>>> o.contentWindow.postMessage("Confidential message", "*"); >>>>>>>> >>>>>>>> Valid code: >>>>>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>>>>> o.contentWindow.postMessage("Confidential message", " >>>>>>>> http://sender-domain.com"); >>>>>>>> >>>>>>>> What do you think ? >>>>>>>> >>>>>>>> [1] http://www.w3.org/TR/2011/WD-webmessaging-20110317/ >>>>>>>> >>>>>>>> Thanks in advance. >>>>>>>> -- >>>>>>>> Cordialement, Best regards, >>>>>>>> Dominique Righetto >>>>>>>> dominique.righetto at gmail.com >>>>>>>> GPG: 323D19BA >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Owasp_sonarqube mailing list >>>>>>>> Owasp_sonarqube at lists.owasp.org >>>>>>>> https://lists.owasp.org/mailman/listinfo/owasp_sonarqube >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominique.righetto at gmail.com Wed Oct 28 14:35:57 2015 From: dominique.righetto at gmail.com (Dominique Righetto) Date: Wed, 28 Oct 2015 15:35:57 +0100 Subject: [Owasp_sonarqube] New rule spec proposal for JavaScript In-Reply-To: References: Message-ID: We can throw a warning if the "origin" attribute is not used into the message handler no ? -- Cordialement, Best regards, Dominique Righetto dominique.righetto at gmail.com GPG: 323D19BA On Wed, Oct 28, 2015 at 3:34 PM, G. Ann Campbell < ann.campbell at sonarsource.com> wrote: > From a coder's point of view, it seems like a regex would be a sufficient > check. But from our point of view, we'd never be able to know if the regex > was "good" for that situation. > > > > --- > *G. Ann CAMPBELL* | SonarSource > Product Owner > http://sonarsource.com > > On Wed, Oct 28, 2015 at 10:26 AM, Dominique Righetto < > dominique.righetto at gmail.com> wrote: > >> Thanks for your response :) >> >> A correct use of "origin" should be to perform a comparison of the >> "origin" attribute value coming from the event against a value. >> >> Ex: >> function receiver(e) { >> if(e.origin == "XXX"){ >> //do stuff >> } >> } >> >> We can check if the "origin" parameter is used in the function associated >> to the "message" event type. >> >> What do you think ? >> >> -- >> Cordialement, Best regards, >> Dominique Righetto >> dominique.righetto at gmail.com >> GPG: 323D19BA >> >> On Wed, Oct 28, 2015 at 1:42 PM, G. Ann Campbell < >> ann.campbell at sonarsource.com> wrote: >> >>> If I'm understanding correctly @Dominique, it would be extremely >>> difficult: what does a proper validation look like? And what if it's handed >>> off to another function? A function in another file? >>> >>> We would only reliably be able to flag uses of origin, and say something >>> like "make sure this message is from a trusted source". >>> >>> >>> >>> --- >>> *G. Ann CAMPBELL* | SonarSource >>> Product Owner >>> http://sonarsource.com >>> >>> On Wed, Oct 28, 2015 at 8:36 AM, Dominique Righetto < >>> dominique.righetto at gmail.com> wrote: >>> >>>> In the same way, do you think that SonarQube rule engine will be able >>>> to detect (if I propose a dedicated rule spec) the non validation of the >>>> event sender (origin) in the message handler on receiver side ? >>>> >>>> Example of handler code on receiver side: >>>> window.addEventListener('message', receiver); >>>> function receiver(e) { >>>> var msg = "Received message from Origin '" + e.origin + "' => '" + >>>> e.data + "'"; >>>> //do stuff... >>>> } >>>> >>>> Thanks in advance :) >>>> >>>> >>>> -- >>>> Cordialement, Best regards, >>>> Dominique Righetto >>>> dominique.righetto at gmail.com >>>> GPG: 323D19BA >>>> >>>> On Wed, Oct 28, 2015 at 12:35 PM, Dominique Righetto < >>>> dominique.righetto at gmail.com> wrote: >>>> >>>>> Raising an issue whenever window.postMessage is used, is for my >>>>> personal opinion, not a good way because it will cause a false-positive if >>>>> the use of the method is correct like in the compliant code sample...The >>>>> implication is that rule will be disabled by dev team if it cause >>>>> false-positive. >>>>> >>>>> I see that the resolution status is "unresolved" is it normal if the >>>>> rule is implemented ? >>>>> >>>>> Thanks for the quote :) >>>>> >>>>> -- >>>>> Cordialement, Best regards, >>>>> Dominique Righetto >>>>> dominique.righetto at gmail.com >>>>> GPG: 323D19BA >>>>> >>>>> On Wed, Oct 28, 2015 at 12:20 PM, G. Ann Campbell < >>>>> ann.campbell at sonarsource.com> wrote: >>>>> >>>>>> Well, your noncompliant code sample is basically the same as mine, >>>>>> and I can't use your compliant solution because the rule raises an issue >>>>>> whenever window.postMessage is used. But I did add your specification quote. >>>>>> >>>>>> BTW, this is already implemented >>>>>> . >>>>>> >>>>>> >>>>>> >>>>>> --- >>>>>> *G. Ann CAMPBELL* | SonarSource >>>>>> Product Owner >>>>>> http://sonarsource.com >>>>>> >>>>>> On Wed, Oct 28, 2015 at 7:07 AM, Dominique Righetto < >>>>>> dominique.righetto at gmail.com> wrote: >>>>>> >>>>>>> Thanks for the ref :) >>>>>>> >>>>>>> Is it possible to enhance the description and code samples with >>>>>>> infos that I have provided ? >>>>>>> >>>>>>> What do you think ? >>>>>>> >>>>>>> -- >>>>>>> Cordialement, Best regards, >>>>>>> Dominique Righetto >>>>>>> dominique.righetto at gmail.com >>>>>>> GPG: 323D19BA >>>>>>> >>>>>>> On Wed, Oct 28, 2015 at 11:57 AM, G. Ann Campbell < >>>>>>> ann.campbell at sonarsource.com> wrote: >>>>>>> >>>>>>>> Beat you to it! :-) >>>>>>>> >>>>>>>> >>>>>>>> 1. RSPEC-2819 Cross-document >>>>>>>> messaging domains should be carefully restricted >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --- >>>>>>>> *G. Ann CAMPBELL* | SonarSource >>>>>>>> Product Owner >>>>>>>> http://sonarsource.com >>>>>>>> >>>>>>>> On Wed, Oct 28, 2015 at 6:03 AM, Dominique Righetto < >>>>>>>> dominique.righetto at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I send you this mail in order to propose a new rule spec for >>>>>>>>> JavaScript. >>>>>>>>> >>>>>>>>> It's about HTML5 Cross Document Messaging feature [1] >>>>>>>>> >>>>>>>>> For exchange messages, the window.postMessage(message, >>>>>>>>> targetOrigin) function is used and the target origin is specified in the >>>>>>>>> second parameter after the message content. >>>>>>>>> >>>>>>>>> As it's specified into the specification (section 4.2.1): >>>>>>>>> >>>>>>>>> "Authors should not use the wildcard keyword (*) in the >>>>>>>>> targetOrigin argument in messages that contain any confidential >>>>>>>>> information, as otherwise there is no way to guarantee that the message is >>>>>>>>> only delivered to the recipient to which it was intended." >>>>>>>>> >>>>>>>>> It can be interesting to add a new rule to detect use of "*" >>>>>>>>> keyword into target origin parameter in case of use of Cross Document >>>>>>>>> Messaging feature. >>>>>>>>> >>>>>>>>> Spotted code: >>>>>>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>>>>>> o.contentWindow.postMessage("Confidential message", "*"); >>>>>>>>> >>>>>>>>> Valid code: >>>>>>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>>>>>> o.contentWindow.postMessage("Confidential message", " >>>>>>>>> http://sender-domain.com"); >>>>>>>>> >>>>>>>>> What do you think ? >>>>>>>>> >>>>>>>>> [1] http://www.w3.org/TR/2011/WD-webmessaging-20110317/ >>>>>>>>> >>>>>>>>> Thanks in advance. >>>>>>>>> -- >>>>>>>>> Cordialement, Best regards, >>>>>>>>> Dominique Righetto >>>>>>>>> dominique.righetto at gmail.com >>>>>>>>> GPG: 323D19BA >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Owasp_sonarqube mailing list >>>>>>>>> Owasp_sonarqube at lists.owasp.org >>>>>>>>> https://lists.owasp.org/mailman/listinfo/owasp_sonarqube >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ann.campbell at sonarsource.com Wed Oct 28 14:43:11 2015 From: ann.campbell at sonarsource.com (G. Ann Campbell) Date: Wed, 28 Oct 2015 10:43:11 -0400 Subject: [Owasp_sonarqube] New rule spec proposal for JavaScript In-Reply-To: References: Message-ID: Okay, with further discussion, I finally get the intent (sorry, that should have happened earlier in the process). That specification exists too: 1. RSPEC-3273 Cross-window message listeners should check message origins --- *G. Ann CAMPBELL* | SonarSource Product Owner http://sonarsource.com On Wed, Oct 28, 2015 at 10:35 AM, Dominique Righetto < dominique.righetto at gmail.com> wrote: > We can throw a warning if the "origin" attribute is not used into the > message handler no ? > > -- > Cordialement, Best regards, > Dominique Righetto > dominique.righetto at gmail.com > GPG: 323D19BA > > On Wed, Oct 28, 2015 at 3:34 PM, G. Ann Campbell < > ann.campbell at sonarsource.com> wrote: > >> From a coder's point of view, it seems like a regex would be a sufficient >> check. But from our point of view, we'd never be able to know if the regex >> was "good" for that situation. >> >> >> >> --- >> *G. Ann CAMPBELL* | SonarSource >> Product Owner >> http://sonarsource.com >> >> On Wed, Oct 28, 2015 at 10:26 AM, Dominique Righetto < >> dominique.righetto at gmail.com> wrote: >> >>> Thanks for your response :) >>> >>> A correct use of "origin" should be to perform a comparison of the >>> "origin" attribute value coming from the event against a value. >>> >>> Ex: >>> function receiver(e) { >>> if(e.origin == "XXX"){ >>> //do stuff >>> } >>> } >>> >>> We can check if the "origin" parameter is used in the function >>> associated to the "message" event type. >>> >>> What do you think ? >>> >>> -- >>> Cordialement, Best regards, >>> Dominique Righetto >>> dominique.righetto at gmail.com >>> GPG: 323D19BA >>> >>> On Wed, Oct 28, 2015 at 1:42 PM, G. Ann Campbell < >>> ann.campbell at sonarsource.com> wrote: >>> >>>> If I'm understanding correctly @Dominique, it would be extremely >>>> difficult: what does a proper validation look like? And what if it's handed >>>> off to another function? A function in another file? >>>> >>>> We would only reliably be able to flag uses of origin, and say >>>> something like "make sure this message is from a trusted source". >>>> >>>> >>>> >>>> --- >>>> *G. Ann CAMPBELL* | SonarSource >>>> Product Owner >>>> http://sonarsource.com >>>> >>>> On Wed, Oct 28, 2015 at 8:36 AM, Dominique Righetto < >>>> dominique.righetto at gmail.com> wrote: >>>> >>>>> In the same way, do you think that SonarQube rule engine will be able >>>>> to detect (if I propose a dedicated rule spec) the non validation of the >>>>> event sender (origin) in the message handler on receiver side ? >>>>> >>>>> Example of handler code on receiver side: >>>>> window.addEventListener('message', receiver); >>>>> function receiver(e) { >>>>> var msg = "Received message from Origin '" + e.origin + "' => '" + >>>>> e.data + "'"; >>>>> //do stuff... >>>>> } >>>>> >>>>> Thanks in advance :) >>>>> >>>>> >>>>> -- >>>>> Cordialement, Best regards, >>>>> Dominique Righetto >>>>> dominique.righetto at gmail.com >>>>> GPG: 323D19BA >>>>> >>>>> On Wed, Oct 28, 2015 at 12:35 PM, Dominique Righetto < >>>>> dominique.righetto at gmail.com> wrote: >>>>> >>>>>> Raising an issue whenever window.postMessage is used, is for my >>>>>> personal opinion, not a good way because it will cause a false-positive if >>>>>> the use of the method is correct like in the compliant code sample...The >>>>>> implication is that rule will be disabled by dev team if it cause >>>>>> false-positive. >>>>>> >>>>>> I see that the resolution status is "unresolved" is it normal if the >>>>>> rule is implemented ? >>>>>> >>>>>> Thanks for the quote :) >>>>>> >>>>>> -- >>>>>> Cordialement, Best regards, >>>>>> Dominique Righetto >>>>>> dominique.righetto at gmail.com >>>>>> GPG: 323D19BA >>>>>> >>>>>> On Wed, Oct 28, 2015 at 12:20 PM, G. Ann Campbell < >>>>>> ann.campbell at sonarsource.com> wrote: >>>>>> >>>>>>> Well, your noncompliant code sample is basically the same as mine, >>>>>>> and I can't use your compliant solution because the rule raises an issue >>>>>>> whenever window.postMessage is used. But I did add your specification quote. >>>>>>> >>>>>>> BTW, this is already implemented >>>>>>> >>>>>>> . >>>>>>> >>>>>>> >>>>>>> >>>>>>> --- >>>>>>> *G. Ann CAMPBELL* | SonarSource >>>>>>> Product Owner >>>>>>> http://sonarsource.com >>>>>>> >>>>>>> On Wed, Oct 28, 2015 at 7:07 AM, Dominique Righetto < >>>>>>> dominique.righetto at gmail.com> wrote: >>>>>>> >>>>>>>> Thanks for the ref :) >>>>>>>> >>>>>>>> Is it possible to enhance the description and code samples with >>>>>>>> infos that I have provided ? >>>>>>>> >>>>>>>> What do you think ? >>>>>>>> >>>>>>>> -- >>>>>>>> Cordialement, Best regards, >>>>>>>> Dominique Righetto >>>>>>>> dominique.righetto at gmail.com >>>>>>>> GPG: 323D19BA >>>>>>>> >>>>>>>> On Wed, Oct 28, 2015 at 11:57 AM, G. Ann Campbell < >>>>>>>> ann.campbell at sonarsource.com> wrote: >>>>>>>> >>>>>>>>> Beat you to it! :-) >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. RSPEC-2819 Cross-document >>>>>>>>> messaging domains should be carefully restricted >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --- >>>>>>>>> *G. Ann CAMPBELL* | SonarSource >>>>>>>>> Product Owner >>>>>>>>> http://sonarsource.com >>>>>>>>> >>>>>>>>> On Wed, Oct 28, 2015 at 6:03 AM, Dominique Righetto < >>>>>>>>> dominique.righetto at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I send you this mail in order to propose a new rule spec for >>>>>>>>>> JavaScript. >>>>>>>>>> >>>>>>>>>> It's about HTML5 Cross Document Messaging feature [1] >>>>>>>>>> >>>>>>>>>> For exchange messages, the window.postMessage(message, >>>>>>>>>> targetOrigin) function is used and the target origin is specified in the >>>>>>>>>> second parameter after the message content. >>>>>>>>>> >>>>>>>>>> As it's specified into the specification (section 4.2.1): >>>>>>>>>> >>>>>>>>>> "Authors should not use the wildcard keyword (*) in the >>>>>>>>>> targetOrigin argument in messages that contain any confidential >>>>>>>>>> information, as otherwise there is no way to guarantee that the message is >>>>>>>>>> only delivered to the recipient to which it was intended." >>>>>>>>>> >>>>>>>>>> It can be interesting to add a new rule to detect use of "*" >>>>>>>>>> keyword into target origin parameter in case of use of Cross Document >>>>>>>>>> Messaging feature. >>>>>>>>>> >>>>>>>>>> Spotted code: >>>>>>>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>>>>>>> o.contentWindow.postMessage("Confidential message", "*"); >>>>>>>>>> >>>>>>>>>> Valid code: >>>>>>>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>>>>>>> o.contentWindow.postMessage("Confidential message", " >>>>>>>>>> http://sender-domain.com"); >>>>>>>>>> >>>>>>>>>> What do you think ? >>>>>>>>>> >>>>>>>>>> [1] http://www.w3.org/TR/2011/WD-webmessaging-20110317/ >>>>>>>>>> >>>>>>>>>> Thanks in advance. >>>>>>>>>> -- >>>>>>>>>> Cordialement, Best regards, >>>>>>>>>> Dominique Righetto >>>>>>>>>> dominique.righetto at gmail.com >>>>>>>>>> GPG: 323D19BA >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Owasp_sonarqube mailing list >>>>>>>>>> Owasp_sonarqube at lists.owasp.org >>>>>>>>>> https://lists.owasp.org/mailman/listinfo/owasp_sonarqube >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominique.righetto at gmail.com Wed Oct 28 14:44:15 2015 From: dominique.righetto at gmail.com (Dominique Righetto) Date: Wed, 28 Oct 2015 15:44:15 +0100 Subject: [Owasp_sonarqube] New rule spec proposal for JavaScript In-Reply-To: References: Message-ID: OK thanks :) Subject closed. -- Cordialement, Best regards, Dominique Righetto dominique.righetto at gmail.com GPG: 323D19BA On Wed, Oct 28, 2015 at 3:43 PM, G. Ann Campbell < ann.campbell at sonarsource.com> wrote: > Okay, with further discussion, I finally get the intent (sorry, that > should have happened earlier in the process). > > That specification exists too: > > > 1. RSPEC-3273 Cross-window > message listeners should check message origins > > > > > --- > *G. Ann CAMPBELL* | SonarSource > Product Owner > http://sonarsource.com > > On Wed, Oct 28, 2015 at 10:35 AM, Dominique Righetto < > dominique.righetto at gmail.com> wrote: > >> We can throw a warning if the "origin" attribute is not used into the >> message handler no ? >> >> -- >> Cordialement, Best regards, >> Dominique Righetto >> dominique.righetto at gmail.com >> GPG: 323D19BA >> >> On Wed, Oct 28, 2015 at 3:34 PM, G. Ann Campbell < >> ann.campbell at sonarsource.com> wrote: >> >>> From a coder's point of view, it seems like a regex would be a >>> sufficient check. But from our point of view, we'd never be able to know if >>> the regex was "good" for that situation. >>> >>> >>> >>> --- >>> *G. Ann CAMPBELL* | SonarSource >>> Product Owner >>> http://sonarsource.com >>> >>> On Wed, Oct 28, 2015 at 10:26 AM, Dominique Righetto < >>> dominique.righetto at gmail.com> wrote: >>> >>>> Thanks for your response :) >>>> >>>> A correct use of "origin" should be to perform a comparison of the >>>> "origin" attribute value coming from the event against a value. >>>> >>>> Ex: >>>> function receiver(e) { >>>> if(e.origin == "XXX"){ >>>> //do stuff >>>> } >>>> } >>>> >>>> We can check if the "origin" parameter is used in the function >>>> associated to the "message" event type. >>>> >>>> What do you think ? >>>> >>>> -- >>>> Cordialement, Best regards, >>>> Dominique Righetto >>>> dominique.righetto at gmail.com >>>> GPG: 323D19BA >>>> >>>> On Wed, Oct 28, 2015 at 1:42 PM, G. Ann Campbell < >>>> ann.campbell at sonarsource.com> wrote: >>>> >>>>> If I'm understanding correctly @Dominique, it would be extremely >>>>> difficult: what does a proper validation look like? And what if it's handed >>>>> off to another function? A function in another file? >>>>> >>>>> We would only reliably be able to flag uses of origin, and say >>>>> something like "make sure this message is from a trusted source". >>>>> >>>>> >>>>> >>>>> --- >>>>> *G. Ann CAMPBELL* | SonarSource >>>>> Product Owner >>>>> http://sonarsource.com >>>>> >>>>> On Wed, Oct 28, 2015 at 8:36 AM, Dominique Righetto < >>>>> dominique.righetto at gmail.com> wrote: >>>>> >>>>>> In the same way, do you think that SonarQube rule engine will be able >>>>>> to detect (if I propose a dedicated rule spec) the non validation of the >>>>>> event sender (origin) in the message handler on receiver side ? >>>>>> >>>>>> Example of handler code on receiver side: >>>>>> window.addEventListener('message', receiver); >>>>>> function receiver(e) { >>>>>> var msg = "Received message from Origin '" + e.origin + "' => '" >>>>>> + e.data + "'"; >>>>>> //do stuff... >>>>>> } >>>>>> >>>>>> Thanks in advance :) >>>>>> >>>>>> >>>>>> -- >>>>>> Cordialement, Best regards, >>>>>> Dominique Righetto >>>>>> dominique.righetto at gmail.com >>>>>> GPG: 323D19BA >>>>>> >>>>>> On Wed, Oct 28, 2015 at 12:35 PM, Dominique Righetto < >>>>>> dominique.righetto at gmail.com> wrote: >>>>>> >>>>>>> Raising an issue whenever window.postMessage is used, is for my >>>>>>> personal opinion, not a good way because it will cause a false-positive if >>>>>>> the use of the method is correct like in the compliant code sample...The >>>>>>> implication is that rule will be disabled by dev team if it cause >>>>>>> false-positive. >>>>>>> >>>>>>> I see that the resolution status is "unresolved" is it normal if the >>>>>>> rule is implemented ? >>>>>>> >>>>>>> Thanks for the quote :) >>>>>>> >>>>>>> -- >>>>>>> Cordialement, Best regards, >>>>>>> Dominique Righetto >>>>>>> dominique.righetto at gmail.com >>>>>>> GPG: 323D19BA >>>>>>> >>>>>>> On Wed, Oct 28, 2015 at 12:20 PM, G. Ann Campbell < >>>>>>> ann.campbell at sonarsource.com> wrote: >>>>>>> >>>>>>>> Well, your noncompliant code sample is basically the same as mine, >>>>>>>> and I can't use your compliant solution because the rule raises an issue >>>>>>>> whenever window.postMessage is used. But I did add your specification quote. >>>>>>>> >>>>>>>> BTW, this is already implemented >>>>>>>> >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --- >>>>>>>> *G. Ann CAMPBELL* | SonarSource >>>>>>>> Product Owner >>>>>>>> http://sonarsource.com >>>>>>>> >>>>>>>> On Wed, Oct 28, 2015 at 7:07 AM, Dominique Righetto < >>>>>>>> dominique.righetto at gmail.com> wrote: >>>>>>>> >>>>>>>>> Thanks for the ref :) >>>>>>>>> >>>>>>>>> Is it possible to enhance the description and code samples with >>>>>>>>> infos that I have provided ? >>>>>>>>> >>>>>>>>> What do you think ? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Cordialement, Best regards, >>>>>>>>> Dominique Righetto >>>>>>>>> dominique.righetto at gmail.com >>>>>>>>> GPG: 323D19BA >>>>>>>>> >>>>>>>>> On Wed, Oct 28, 2015 at 11:57 AM, G. Ann Campbell < >>>>>>>>> ann.campbell at sonarsource.com> wrote: >>>>>>>>> >>>>>>>>>> Beat you to it! :-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1. RSPEC-2819 >>>>>>>>>> Cross-document messaging domains should be carefully >>>>>>>>>> restricted >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> *G. Ann CAMPBELL* | SonarSource >>>>>>>>>> Product Owner >>>>>>>>>> http://sonarsource.com >>>>>>>>>> >>>>>>>>>> On Wed, Oct 28, 2015 at 6:03 AM, Dominique Righetto < >>>>>>>>>> dominique.righetto at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I send you this mail in order to propose a new rule spec for >>>>>>>>>>> JavaScript. >>>>>>>>>>> >>>>>>>>>>> It's about HTML5 Cross Document Messaging feature [1] >>>>>>>>>>> >>>>>>>>>>> For exchange messages, the window.postMessage(message, >>>>>>>>>>> targetOrigin) function is used and the target origin is specified in the >>>>>>>>>>> second parameter after the message content. >>>>>>>>>>> >>>>>>>>>>> As it's specified into the specification (section 4.2.1): >>>>>>>>>>> >>>>>>>>>>> "Authors should not use the wildcard keyword (*) in the >>>>>>>>>>> targetOrigin argument in messages that contain any confidential >>>>>>>>>>> information, as otherwise there is no way to guarantee that the message is >>>>>>>>>>> only delivered to the recipient to which it was intended." >>>>>>>>>>> >>>>>>>>>>> It can be interesting to add a new rule to detect use of "*" >>>>>>>>>>> keyword into target origin parameter in case of use of Cross Document >>>>>>>>>>> Messaging feature. >>>>>>>>>>> >>>>>>>>>>> Spotted code: >>>>>>>>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>>>>>>>> o.contentWindow.postMessage("Confidential message", "*"); >>>>>>>>>>> >>>>>>>>>>> Valid code: >>>>>>>>>>> var o = document.getElementsByTagName('iframe')[0]; >>>>>>>>>>> o.contentWindow.postMessage("Confidential message", " >>>>>>>>>>> http://sender-domain.com"); >>>>>>>>>>> >>>>>>>>>>> What do you think ? >>>>>>>>>>> >>>>>>>>>>> [1] http://www.w3.org/TR/2011/WD-webmessaging-20110317/ >>>>>>>>>>> >>>>>>>>>>> Thanks in advance. >>>>>>>>>>> -- >>>>>>>>>>> Cordialement, Best regards, >>>>>>>>>>> Dominique Righetto >>>>>>>>>>> dominique.righetto at gmail.com >>>>>>>>>>> GPG: 323D19BA >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Owasp_sonarqube mailing list >>>>>>>>>>> Owasp_sonarqube at lists.owasp.org >>>>>>>>>>> https://lists.owasp.org/mailman/listinfo/owasp_sonarqube >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: