Re: [Dev] DSS Tryit Page issue

[Manuri Amaya Perera]

On Tuesday, 21 June 2016, Ayoma Wijethunga  wrote:

> Hi Team,
>
> Identified that *"issue 1"* occurred because TryIt does not load the
> "csrfPrevention.js" JavaScript, which is responsible of injecting CSRF
> token values into request. This is because TryIt application does not have
> the usual carbon template applied.
>
> [1] should fix the issue. I have verified this by modifying HTML content
> using BurpSuite. However, I was unable to test same with DSS because I
> cannot find "org.wso2.carbon.wsdl2form-4.5.3.jar" in any of the
> library/plugins folders, even though it is available in
> "./repository/components/default/configuration/org.eclipse.osgi/bundles/"
> folder after server start. I didn't create the PR since, I could not test
> it locally. Any advice on this?
>

Thank you Ayoma for working on resolving the issue. This jar can be found
inside org.wso2.carbon.tryit jar. It is an embedded dependency of tryit
bundle.

>
> Also, do we have any other applications such as "TryIt" that does not have
> the usual carbon template applied, but uses resources available within
> "/carbon" context (ex : /carbon/admin/jsp/WSRequestXSSproxy_
> ajaxprocessor.jsp).
>
> [1] https://github.com/wso2/carbon-commons/compare/4.4.x...ayomawdb:4.4.x
>
> Regards,
> Ayoma.
>
> On Tue, Jun 21, 2016 at 5:38 PM, Manuri Amaya Perera  > wrote:
>
>> Hi,
>>
>> I have added content type in tryit.xslt and sent a PR[1]. This resolved
>> issue 2.
>>
>>
>> [1] https://wso2.org/jira/browse/CCOMMONS-16
>>
>> On Tue, Jun 21, 2016 at 4:01 PM, Manuri Amaya Perera > > wrote:
>>
>>> Hi Ayoma,
>>>
>>> I think setting the content-type can be done in [1].
>>>
>>> But this issue should occur for other products as well right?
>>>
>>> [1]
>>> https://github.com/wso2/carbon-commons/blob/master/components/wsdl2form/org.wso2.carbon.wsdl2form/src/main/java/org/wso2/carbon/wsdl2form/WSDL2FormRequestProcessor.java
>>>
>>> Thanks,
>>> Manuri
>>>
>>> On Tue, Jun 21, 2016 at 3:55 PM, Ayoma Wijethunga >> > wrote:
>>>
 Hi Team,

 As Manuri mentioned, "issue 2" occurs because we are serving a
 JavaScript as the response for service call [1] with the content-type
 "text/html". This should be corrected to "application/javascript".

 Is there any possibility for us to send the "content-type" header in
 the response, based on the extension of the resource being loaded? This is
 the correct way forward.

 Issue is relevant to "X-Content-Type-Options:nosniff" header Tomcat
 filter is setting to prevent "MIME Sniffing" attacks. Also this is separate
 form CSRFGuard.

 [1]
 http://10.100.7.67:9783/services/echo?wsdl2form=editarea/edit_area_full.js
 [2] http://www.slideshare.net/RonanDunne1/mime-sniffing-17014318

 Regards,
 Ayoma.

 On Tue, Jun 21, 2016 at 3:41 PM, Manuri Amaya Perera > wrote:

>
>
> On Tue, Jun 21, 2016 at 3:26 PM, KasunG Gajasinghe  > wrote:
>
>>
>>
>> On Tue, Jun 21, 2016 at 2:37 PM, Manuri Amaya Perera <
>> manu...@wso2.com >
>> wrote:
>>
>>> Hi all,
>>>
>>> Please find the comments inline.
>>>
>>> On Tue, Jun 21, 2016 at 9:48 AM, Anupama Pathirage >> > wrote:
>>>
 Hi,

 When we build the product DSS [1] with the latest Kernel Release
 (4.4.6), we have observed following issues in "Try it" page.  
 Appreciate
 any clue on this to get them resolved.

 *1) *In Https mode, Try it requests gives following error on send
 [2][3].

 WARN {org.owasp.csrfguard.log.JavaLogger} -  potential cross-site
 request forgery (CSRF) attack thwarted (user:, 
 ip:10.100.7.118,
 method:POST, uri:/carbon/admin/jsp/WSRequestXSSproxy_ajaxprocessor.jsp,
 error:required token is missing from the request)

 Private proxy protocol will be attempted as cross-domain browser
 restrictions might be enforced for this endpoint.

 http://tryit.carbon.wso2.org;>
Error connecting to the Tryit ajax proxy
 

 *2)* Try it page does not load properly in Chrome. It loads
 correctly in Firefox. It gives the following error on chrome [4].

 Refused to execute script from '
 https://localhost:9443/services/echo?wsdl2form=editarea/edit_area_full.js'
 

Re: [Dev] DSS Tryit Page issue

[Ayoma Wijethunga]

Hi Team,

Identified that *"issue 1"* occurred because TryIt does not load the
"csrfPrevention.js" JavaScript, which is responsible of injecting CSRF
token values into request. This is because TryIt application does not have
the usual carbon template applied.

[1] should fix the issue. I have verified this by modifying HTML content
using BurpSuite. However, I was unable to test same with DSS because I
cannot find "org.wso2.carbon.wsdl2form-4.5.3.jar" in any of the
library/plugins folders, even though it is available in
"./repository/components/default/configuration/org.eclipse.osgi/bundles/"
folder after server start. I didn't create the PR since, I could not test
it locally. Any advice on this?

Also, do we have any other applications such as "TryIt" that does not have
the usual carbon template applied, but uses resources available within
"/carbon" context (ex : /carbon/admin/jsp/WSRequestXSSproxy_
ajaxprocessor.jsp).

[1] https://github.com/wso2/carbon-commons/compare/4.4.x...ayomawdb:4.4.x

Regards,
Ayoma.

On Tue, Jun 21, 2016 at 5:38 PM, Manuri Amaya Perera 
wrote:

> Hi,
>
> I have added content type in tryit.xslt and sent a PR[1]. This resolved
> issue 2.
>
>
> [1] https://wso2.org/jira/browse/CCOMMONS-16
>
> On Tue, Jun 21, 2016 at 4:01 PM, Manuri Amaya Perera 
> wrote:
>
>> Hi Ayoma,
>>
>> I think setting the content-type can be done in [1].
>>
>> But this issue should occur for other products as well right?
>>
>> [1]
>> https://github.com/wso2/carbon-commons/blob/master/components/wsdl2form/org.wso2.carbon.wsdl2form/src/main/java/org/wso2/carbon/wsdl2form/WSDL2FormRequestProcessor.java
>>
>> Thanks,
>> Manuri
>>
>> On Tue, Jun 21, 2016 at 3:55 PM, Ayoma Wijethunga  wrote:
>>
>>> Hi Team,
>>>
>>> As Manuri mentioned, "issue 2" occurs because we are serving a
>>> JavaScript as the response for service call [1] with the content-type
>>> "text/html". This should be corrected to "application/javascript".
>>>
>>> Is there any possibility for us to send the "content-type" header in the
>>> response, based on the extension of the resource being loaded? This is the
>>> correct way forward.
>>>
>>> Issue is relevant to "X-Content-Type-Options:nosniff" header Tomcat
>>> filter is setting to prevent "MIME Sniffing" attacks. Also this is separate
>>> form CSRFGuard.
>>>
>>> [1]
>>> http://10.100.7.67:9783/services/echo?wsdl2form=editarea/edit_area_full.js
>>> [2] http://www.slideshare.net/RonanDunne1/mime-sniffing-17014318
>>>
>>> Regards,
>>> Ayoma.
>>>
>>> On Tue, Jun 21, 2016 at 3:41 PM, Manuri Amaya Perera 
>>> wrote:
>>>


 On Tue, Jun 21, 2016 at 3:26 PM, KasunG Gajasinghe 
 wrote:

>
>
> On Tue, Jun 21, 2016 at 2:37 PM, Manuri Amaya Perera  > wrote:
>
>> Hi all,
>>
>> Please find the comments inline.
>>
>> On Tue, Jun 21, 2016 at 9:48 AM, Anupama Pathirage 
>> wrote:
>>
>>> Hi,
>>>
>>> When we build the product DSS [1] with the latest Kernel Release
>>> (4.4.6), we have observed following issues in "Try it" page.  Appreciate
>>> any clue on this to get them resolved.
>>>
>>> *1) *In Https mode, Try it requests gives following error on send
>>> [2][3].
>>>
>>> WARN {org.owasp.csrfguard.log.JavaLogger} -  potential cross-site
>>> request forgery (CSRF) attack thwarted (user:, 
>>> ip:10.100.7.118,
>>> method:POST, uri:/carbon/admin/jsp/WSRequestXSSproxy_ajaxprocessor.jsp,
>>> error:required token is missing from the request)
>>>
>>> Private proxy protocol will be attempted as cross-domain browser
>>> restrictions might be enforced for this endpoint.
>>>
>>> http://tryit.carbon.wso2.org;>
>>>Error connecting to the Tryit ajax proxy
>>> 
>>>
>>> *2)* Try it page does not load properly in Chrome. It loads
>>> correctly in Firefox. It gives the following error on chrome [4].
>>>
>>> Refused to execute script from '
>>> https://localhost:9443/services/echo?wsdl2form=editarea/edit_area_full.js'
>>> 
>>> because its MIME type ('text/html') is not executable, and strict MIME 
>>> type
>>> checking is enabled.
>>> Uncaught ReferenceError: editAreaLoader is not defined.
>>>
>>
>> ​When downgrading DSS's kernel version to 4.4.5 this issue doesn't
>> occur. When comparing the response to the request
>>
>> http://10.100.7.67:9783/services/echo?wsdl2form=editarea/edit_area_full.js
>>  in DSS with kernel 4.4.5 and kernel 4.4.6 it seems some additional
>> headers are present in the latter. They were,
>>
>>1. X-Content-Type-Options:
>>nosniff
>>2. X-Frame-Options:
>>  

Re: [Dev] DSS Tryit Page issue

[Manuri Amaya Perera]

Hi,

I have added content type in tryit.xslt and sent a PR[1]. This resolved
issue 2.


[1] https://wso2.org/jira/browse/CCOMMONS-16

On Tue, Jun 21, 2016 at 4:01 PM, Manuri Amaya Perera 
wrote:

> Hi Ayoma,
>
> I think setting the content-type can be done in [1].
>
> But this issue should occur for other products as well right?
>
> [1]
> https://github.com/wso2/carbon-commons/blob/master/components/wsdl2form/org.wso2.carbon.wsdl2form/src/main/java/org/wso2/carbon/wsdl2form/WSDL2FormRequestProcessor.java
>
> Thanks,
> Manuri
>
> On Tue, Jun 21, 2016 at 3:55 PM, Ayoma Wijethunga  wrote:
>
>> Hi Team,
>>
>> As Manuri mentioned, "issue 2" occurs because we are serving a JavaScript
>> as the response for service call [1] with the content-type "text/html".
>> This should be corrected to "application/javascript".
>>
>> Is there any possibility for us to send the "content-type" header in the
>> response, based on the extension of the resource being loaded? This is the
>> correct way forward.
>>
>> Issue is relevant to "X-Content-Type-Options:nosniff" header Tomcat
>> filter is setting to prevent "MIME Sniffing" attacks. Also this is separate
>> form CSRFGuard.
>>
>> [1]
>> http://10.100.7.67:9783/services/echo?wsdl2form=editarea/edit_area_full.js
>> [2] http://www.slideshare.net/RonanDunne1/mime-sniffing-17014318
>>
>> Regards,
>> Ayoma.
>>
>> On Tue, Jun 21, 2016 at 3:41 PM, Manuri Amaya Perera 
>> wrote:
>>
>>>
>>>
>>> On Tue, Jun 21, 2016 at 3:26 PM, KasunG Gajasinghe 
>>> wrote:
>>>


 On Tue, Jun 21, 2016 at 2:37 PM, Manuri Amaya Perera 
 wrote:

> Hi all,
>
> Please find the comments inline.
>
> On Tue, Jun 21, 2016 at 9:48 AM, Anupama Pathirage 
> wrote:
>
>> Hi,
>>
>> When we build the product DSS [1] with the latest Kernel Release
>> (4.4.6), we have observed following issues in "Try it" page.  Appreciate
>> any clue on this to get them resolved.
>>
>> *1) *In Https mode, Try it requests gives following error on send
>> [2][3].
>>
>> WARN {org.owasp.csrfguard.log.JavaLogger} -  potential cross-site
>> request forgery (CSRF) attack thwarted (user:, 
>> ip:10.100.7.118,
>> method:POST, uri:/carbon/admin/jsp/WSRequestXSSproxy_ajaxprocessor.jsp,
>> error:required token is missing from the request)
>>
>> Private proxy protocol will be attempted as cross-domain browser
>> restrictions might be enforced for this endpoint.
>>
>> http://tryit.carbon.wso2.org;>
>>Error connecting to the Tryit ajax proxy
>> 
>>
>> *2)* Try it page does not load properly in Chrome. It loads
>> correctly in Firefox. It gives the following error on chrome [4].
>>
>> Refused to execute script from '
>> https://localhost:9443/services/echo?wsdl2form=editarea/edit_area_full.js'
>> 
>> because its MIME type ('text/html') is not executable, and strict MIME 
>> type
>> checking is enabled.
>> Uncaught ReferenceError: editAreaLoader is not defined.
>>
>
> ​When downgrading DSS's kernel version to 4.4.5 this issue doesn't
> occur. When comparing the response to the request
>
> http://10.100.7.67:9783/services/echo?wsdl2form=editarea/edit_area_full.js
>  in DSS with kernel 4.4.5 and kernel 4.4.6 it seems some additional
> headers are present in the latter. They were,
>
>1. X-Content-Type-Options:
>nosniff
>2. X-Frame-Options:
>DENY
>3. X-XSS-Protection:
>1; mode=block
>
> ​Here the ​X-Content-Type-Options header is to make sure the browser
> does not try to detect a different Content-Type than what is actually
> sent[1].
>

 What is the Content-Type (or rather Accept) header sent by the browser?

>>> ​Accept header is */*​
>>>
>>>


> Here the content type of the response is
> text/html
> ​.
> ​Therefore this error occurs for edit_area_full.js file. And it seems
> firefox(at least the version we tested with) ​is not supporting this 
> header
> but chrome does[2], which should be the reason why we don't get this error
> in firefox.
>
> Anyway we built with kernel 4.4.6 and checked this in BPS and it seems
> those additional headers are not present in the response.
>

 If the configurations and the tryit version are the same, then both
 these products should behave in a similar manner.

>>> ​Try it versions are equal. And the
>>> two Owasp.CsrfGuard.Carbon.properties files are identical.
>>>
>>>


>
>
> [1] https://github.com/wso2/product-dss/
>> [2] 

Re: [Dev] DSS Tryit Page issue

[Manuri Amaya Perera]

Hi Ayoma,

I think setting the content-type can be done in [1].

But this issue should occur for other products as well right?

[1]
https://github.com/wso2/carbon-commons/blob/master/components/wsdl2form/org.wso2.carbon.wsdl2form/src/main/java/org/wso2/carbon/wsdl2form/WSDL2FormRequestProcessor.java

Thanks,
Manuri

On Tue, Jun 21, 2016 at 3:55 PM, Ayoma Wijethunga  wrote:

> Hi Team,
>
> As Manuri mentioned, "issue 2" occurs because we are serving a JavaScript
> as the response for service call [1] with the content-type "text/html".
> This should be corrected to "application/javascript".
>
> Is there any possibility for us to send the "content-type" header in the
> response, based on the extension of the resource being loaded? This is the
> correct way forward.
>
> Issue is relevant to "X-Content-Type-Options:nosniff" header Tomcat filter
> is setting to prevent "MIME Sniffing" attacks. Also this is separate form
> CSRFGuard.
>
> [1]
> http://10.100.7.67:9783/services/echo?wsdl2form=editarea/edit_area_full.js
> [2] http://www.slideshare.net/RonanDunne1/mime-sniffing-17014318
>
> Regards,
> Ayoma.
>
> On Tue, Jun 21, 2016 at 3:41 PM, Manuri Amaya Perera 
> wrote:
>
>>
>>
>> On Tue, Jun 21, 2016 at 3:26 PM, KasunG Gajasinghe 
>> wrote:
>>
>>>
>>>
>>> On Tue, Jun 21, 2016 at 2:37 PM, Manuri Amaya Perera 
>>> wrote:
>>>
 Hi all,

 Please find the comments inline.

 On Tue, Jun 21, 2016 at 9:48 AM, Anupama Pathirage 
 wrote:

> Hi,
>
> When we build the product DSS [1] with the latest Kernel Release
> (4.4.6), we have observed following issues in "Try it" page.  Appreciate
> any clue on this to get them resolved.
>
> *1) *In Https mode, Try it requests gives following error on send
> [2][3].
>
> WARN {org.owasp.csrfguard.log.JavaLogger} -  potential cross-site
> request forgery (CSRF) attack thwarted (user:, ip:10.100.7.118,
> method:POST, uri:/carbon/admin/jsp/WSRequestXSSproxy_ajaxprocessor.jsp,
> error:required token is missing from the request)
>
> Private proxy protocol will be attempted as cross-domain browser
> restrictions might be enforced for this endpoint.
>
> http://tryit.carbon.wso2.org;>
>Error connecting to the Tryit ajax proxy
> 
>
> *2)* Try it page does not load properly in Chrome. It loads correctly
> in Firefox. It gives the following error on chrome [4].
>
> Refused to execute script from '
> https://localhost:9443/services/echo?wsdl2form=editarea/edit_area_full.js'
> 
> because its MIME type ('text/html') is not executable, and strict MIME 
> type
> checking is enabled.
> Uncaught ReferenceError: editAreaLoader is not defined.
>

 ​When downgrading DSS's kernel version to 4.4.5 this issue doesn't
 occur. When comparing the response to the request

 http://10.100.7.67:9783/services/echo?wsdl2form=editarea/edit_area_full.js
  in DSS with kernel 4.4.5 and kernel 4.4.6 it seems some additional
 headers are present in the latter. They were,

1. X-Content-Type-Options:
nosniff
2. X-Frame-Options:
DENY
3. X-XSS-Protection:
1; mode=block

 ​Here the ​X-Content-Type-Options header is to make sure the browser
 does not try to detect a different Content-Type than what is actually
 sent[1].

>>>
>>> What is the Content-Type (or rather Accept) header sent by the browser?
>>>
>> ​Accept header is */*​
>>
>>
>>>
>>>
 Here the content type of the response is
 text/html
 ​.
 ​Therefore this error occurs for edit_area_full.js file. And it seems
 firefox(at least the version we tested with) ​is not supporting this header
 but chrome does[2], which should be the reason why we don't get this error
 in firefox.

 Anyway we built with kernel 4.4.6 and checked this in BPS and it seems
 those additional headers are not present in the response.

>>>
>>> If the configurations and the tryit version are the same, then both
>>> these products should behave in a similar manner.
>>>
>> ​Try it versions are equal. And the two Owasp.CsrfGuard.Carbon.properties
>> files are identical.
>>
>>
>>>
>>>


 [1] https://github.com/wso2/product-dss/
> [2] https://drive.google.com/open?id=0B16LG8jdYeP8ZEpyV1F5cmRsTDA
> [3] https://drive.google.com/open?id=0B16LG8jdYeP8LWF2elVTbzFQOWs
> [4] https://drive.google.com/open?id=0B16LG8jdYeP8VmtlWXEtdmRJUjQ
>
> Regards,
> --
> Anupama Pathirage
> Associate Technical Lead
> WSO2, Inc.  http://wso2.com/
> Email: anup...@wso2.com
> Mobile:+94 71 8273 979
>
>
>

Re: [Dev] DSS Tryit Page issue

[Ayoma Wijethunga]

Hi Team,

As Manuri mentioned, "issue 2" occurs because we are serving a JavaScript
as the response for service call [1] with the content-type "text/html".
This should be corrected to "application/javascript".

Is there any possibility for us to send the "content-type" header in the
response, based on the extension of the resource being loaded? This is the
correct way forward.

Issue is relevant to "X-Content-Type-Options:nosniff" header Tomcat filter
is setting to prevent "MIME Sniffing" attacks. Also this is separate form
CSRFGuard.

[1]
http://10.100.7.67:9783/services/echo?wsdl2form=editarea/edit_area_full.js
[2] http://www.slideshare.net/RonanDunne1/mime-sniffing-17014318

Regards,
Ayoma.

On Tue, Jun 21, 2016 at 3:41 PM, Manuri Amaya Perera 
wrote:

>
>
> On Tue, Jun 21, 2016 at 3:26 PM, KasunG Gajasinghe 
> wrote:
>
>>
>>
>> On Tue, Jun 21, 2016 at 2:37 PM, Manuri Amaya Perera 
>> wrote:
>>
>>> Hi all,
>>>
>>> Please find the comments inline.
>>>
>>> On Tue, Jun 21, 2016 at 9:48 AM, Anupama Pathirage 
>>> wrote:
>>>
 Hi,

 When we build the product DSS [1] with the latest Kernel Release
 (4.4.6), we have observed following issues in "Try it" page.  Appreciate
 any clue on this to get them resolved.

 *1) *In Https mode, Try it requests gives following error on send
 [2][3].

 WARN {org.owasp.csrfguard.log.JavaLogger} -  potential cross-site
 request forgery (CSRF) attack thwarted (user:, ip:10.100.7.118,
 method:POST, uri:/carbon/admin/jsp/WSRequestXSSproxy_ajaxprocessor.jsp,
 error:required token is missing from the request)

 Private proxy protocol will be attempted as cross-domain browser
 restrictions might be enforced for this endpoint.

 http://tryit.carbon.wso2.org;>
Error connecting to the Tryit ajax proxy
 

 *2)* Try it page does not load properly in Chrome. It loads correctly
 in Firefox. It gives the following error on chrome [4].

 Refused to execute script from '
 https://localhost:9443/services/echo?wsdl2form=editarea/edit_area_full.js'
 
 because its MIME type ('text/html') is not executable, and strict MIME type
 checking is enabled.
 Uncaught ReferenceError: editAreaLoader is not defined.

>>>
>>> ​When downgrading DSS's kernel version to 4.4.5 this issue doesn't
>>> occur. When comparing the response to the request
>>>
>>> http://10.100.7.67:9783/services/echo?wsdl2form=editarea/edit_area_full.js
>>>  in DSS with kernel 4.4.5 and kernel 4.4.6 it seems some additional
>>> headers are present in the latter. They were,
>>>
>>>1. X-Content-Type-Options:
>>>nosniff
>>>2. X-Frame-Options:
>>>DENY
>>>3. X-XSS-Protection:
>>>1; mode=block
>>>
>>> ​Here the ​X-Content-Type-Options header is to make sure the browser
>>> does not try to detect a different Content-Type than what is actually
>>> sent[1].
>>>
>>
>> What is the Content-Type (or rather Accept) header sent by the browser?
>>
> ​Accept header is */*​
>
>
>>
>>
>>> Here the content type of the response is
>>> text/html
>>> ​.
>>> ​Therefore this error occurs for edit_area_full.js file. And it seems
>>> firefox(at least the version we tested with) ​is not supporting this header
>>> but chrome does[2], which should be the reason why we don't get this error
>>> in firefox.
>>>
>>> Anyway we built with kernel 4.4.6 and checked this in BPS and it seems
>>> those additional headers are not present in the response.
>>>
>>
>> If the configurations and the tryit version are the same, then both these
>> products should behave in a similar manner.
>>
> ​Try it versions are equal. And the two Owasp.CsrfGuard.Carbon.properties
> files are identical.
>
>
>>
>>
>>>
>>>
>>> [1] https://github.com/wso2/product-dss/
 [2] https://drive.google.com/open?id=0B16LG8jdYeP8ZEpyV1F5cmRsTDA
 [3] https://drive.google.com/open?id=0B16LG8jdYeP8LWF2elVTbzFQOWs
 [4] https://drive.google.com/open?id=0B16LG8jdYeP8VmtlWXEtdmRJUjQ

 Regards,
 --
 Anupama Pathirage
 Associate Technical Lead
 WSO2, Inc.  http://wso2.com/
 Email: anup...@wso2.com
 Mobile:+94 71 8273 979



>>>
>>> ​[1] https://www.owasp.org/index.php/REST_Security_Cheat_Sheet​
>>> ​[2]
>>> http://stackoverflow.com/questions/18337630/what-is-x-content-type-options-nosniff​
>>>
>>> ​Thanks,
>>> Manuri​
>>>
>>> --
>>>
>>> *Manuri Amaya Perera*
>>>
>>> *Software Engineer*
>>>
>>> *WSO2 Inc.*
>>>
>>> *Blog: http://manuriamayaperera.blogspot.com
>>> *
>>>
>>
>>
>>
>> --
>>
>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>> email: kasung AT spamfree wso2.com
>> linked-in: http://lk.linkedin.com/in/gajasinghe
>> blog: 

Re: [Dev] DSS Tryit Page issue

[Manuri Amaya Perera]

On Tue, Jun 21, 2016 at 3:26 PM, KasunG Gajasinghe  wrote:

>
>
> On Tue, Jun 21, 2016 at 2:37 PM, Manuri Amaya Perera 
> wrote:
>
>> Hi all,
>>
>> Please find the comments inline.
>>
>> On Tue, Jun 21, 2016 at 9:48 AM, Anupama Pathirage 
>> wrote:
>>
>>> Hi,
>>>
>>> When we build the product DSS [1] with the latest Kernel Release
>>> (4.4.6), we have observed following issues in "Try it" page.  Appreciate
>>> any clue on this to get them resolved.
>>>
>>> *1) *In Https mode, Try it requests gives following error on send
>>> [2][3].
>>>
>>> WARN {org.owasp.csrfguard.log.JavaLogger} -  potential cross-site
>>> request forgery (CSRF) attack thwarted (user:, ip:10.100.7.118,
>>> method:POST, uri:/carbon/admin/jsp/WSRequestXSSproxy_ajaxprocessor.jsp,
>>> error:required token is missing from the request)
>>>
>>> Private proxy protocol will be attempted as cross-domain browser
>>> restrictions might be enforced for this endpoint.
>>>
>>> http://tryit.carbon.wso2.org;>
>>>Error connecting to the Tryit ajax proxy
>>> 
>>>
>>> *2)* Try it page does not load properly in Chrome. It loads correctly
>>> in Firefox. It gives the following error on chrome [4].
>>>
>>> Refused to execute script from '
>>> https://localhost:9443/services/echo?wsdl2form=editarea/edit_area_full.js'
>>> 
>>> because its MIME type ('text/html') is not executable, and strict MIME type
>>> checking is enabled.
>>> Uncaught ReferenceError: editAreaLoader is not defined.
>>>
>>
>> ​When downgrading DSS's kernel version to 4.4.5 this issue doesn't occur.
>> When comparing the response to the request
>>
>> http://10.100.7.67:9783/services/echo?wsdl2form=editarea/edit_area_full.js
>>  in DSS with kernel 4.4.5 and kernel 4.4.6 it seems some additional
>> headers are present in the latter. They were,
>>
>>1. X-Content-Type-Options:
>>nosniff
>>2. X-Frame-Options:
>>DENY
>>3. X-XSS-Protection:
>>1; mode=block
>>
>> ​Here the ​X-Content-Type-Options header is to make sure the browser does
>> not try to detect a different Content-Type than what is actually sent[1].
>>
>
> What is the Content-Type (or rather Accept) header sent by the browser?
>
​Accept header is */*​


>
>
>> Here the content type of the response is
>> text/html
>> ​.
>> ​Therefore this error occurs for edit_area_full.js file. And it seems
>> firefox(at least the version we tested with) ​is not supporting this header
>> but chrome does[2], which should be the reason why we don't get this error
>> in firefox.
>>
>> Anyway we built with kernel 4.4.6 and checked this in BPS and it seems
>> those additional headers are not present in the response.
>>
>
> If the configurations and the tryit version are the same, then both these
> products should behave in a similar manner.
>
​Try it versions are equal. And the two Owasp.CsrfGuard.Carbon.properties
files are identical.


>
>
>>
>>
>> [1] https://github.com/wso2/product-dss/
>>> [2] https://drive.google.com/open?id=0B16LG8jdYeP8ZEpyV1F5cmRsTDA
>>> [3] https://drive.google.com/open?id=0B16LG8jdYeP8LWF2elVTbzFQOWs
>>> [4] https://drive.google.com/open?id=0B16LG8jdYeP8VmtlWXEtdmRJUjQ
>>>
>>> Regards,
>>> --
>>> Anupama Pathirage
>>> Associate Technical Lead
>>> WSO2, Inc.  http://wso2.com/
>>> Email: anup...@wso2.com
>>> Mobile:+94 71 8273 979
>>>
>>>
>>>
>>
>> ​[1] https://www.owasp.org/index.php/REST_Security_Cheat_Sheet​
>> ​[2]
>> http://stackoverflow.com/questions/18337630/what-is-x-content-type-options-nosniff​
>>
>> ​Thanks,
>> Manuri​
>>
>> --
>>
>> *Manuri Amaya Perera*
>>
>> *Software Engineer*
>>
>> *WSO2 Inc.*
>>
>> *Blog: http://manuriamayaperera.blogspot.com
>> *
>>
>
>
>
> --
>
> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
>
>
>



-- 

*Manuri Amaya Perera*

*Software Engineer*

*WSO2 Inc.*

*Blog: http://manuriamayaperera.blogspot.com
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] DSS Tryit Page issue

[KasunG Gajasinghe]

On Tue, Jun 21, 2016 at 2:37 PM, Manuri Amaya Perera 
wrote:

> Hi all,
>
> Please find the comments inline.
>
> On Tue, Jun 21, 2016 at 9:48 AM, Anupama Pathirage 
> wrote:
>
>> Hi,
>>
>> When we build the product DSS [1] with the latest Kernel Release (4.4.6),
>> we have observed following issues in "Try it" page.  Appreciate any clue on
>> this to get them resolved.
>>
>> *1) *In Https mode, Try it requests gives following error on send [2][3].
>>
>> WARN {org.owasp.csrfguard.log.JavaLogger} -  potential cross-site request
>> forgery (CSRF) attack thwarted (user:, ip:10.100.7.118,
>> method:POST, uri:/carbon/admin/jsp/WSRequestXSSproxy_ajaxprocessor.jsp,
>> error:required token is missing from the request)
>>
>> Private proxy protocol will be attempted as cross-domain browser
>> restrictions might be enforced for this endpoint.
>>
>> http://tryit.carbon.wso2.org;>
>>Error connecting to the Tryit ajax proxy
>> 
>>
>> *2)* Try it page does not load properly in Chrome. It loads correctly in
>> Firefox. It gives the following error on chrome [4].
>>
>> Refused to execute script from '
>> https://localhost:9443/services/echo?wsdl2form=editarea/edit_area_full.js'
>> 
>> because its MIME type ('text/html') is not executable, and strict MIME type
>> checking is enabled.
>> Uncaught ReferenceError: editAreaLoader is not defined.
>>
>
> ​When downgrading DSS's kernel version to 4.4.5 this issue doesn't occur.
> When comparing the response to the request
>
> http://10.100.7.67:9783/services/echo?wsdl2form=editarea/edit_area_full.js
>  in DSS with kernel 4.4.5 and kernel 4.4.6 it seems some additional
> headers are present in the latter. They were,
>
>1. X-Content-Type-Options:
>nosniff
>2. X-Frame-Options:
>DENY
>3. X-XSS-Protection:
>1; mode=block
>
> ​Here the ​X-Content-Type-Options header is to make sure the browser does
> not try to detect a different Content-Type than what is actually sent[1].
>

What is the Content-Type (or rather Accept) header sent by the browser?


> Here the content type of the response is
> text/html
> ​.
> ​Therefore this error occurs for edit_area_full.js file. And it seems
> firefox(at least the version we tested with) ​is not supporting this header
> but chrome does[2], which should be the reason why we don't get this error
> in firefox.
>
> Anyway we built with kernel 4.4.6 and checked this in BPS and it seems
> those additional headers are not present in the response.
>

If the configurations and the tryit version are the same, then both these
products should behave in a similar manner.


>
>
> [1] https://github.com/wso2/product-dss/
>> [2] https://drive.google.com/open?id=0B16LG8jdYeP8ZEpyV1F5cmRsTDA
>> [3] https://drive.google.com/open?id=0B16LG8jdYeP8LWF2elVTbzFQOWs
>> [4] https://drive.google.com/open?id=0B16LG8jdYeP8VmtlWXEtdmRJUjQ
>>
>> Regards,
>> --
>> Anupama Pathirage
>> Associate Technical Lead
>> WSO2, Inc.  http://wso2.com/
>> Email: anup...@wso2.com
>> Mobile:+94 71 8273 979
>>
>>
>>
>
> ​[1] https://www.owasp.org/index.php/REST_Security_Cheat_Sheet​
> ​[2]
> http://stackoverflow.com/questions/18337630/what-is-x-content-type-options-nosniff​
>
> ​Thanks,
> Manuri​
>
> --
>
> *Manuri Amaya Perera*
>
> *Software Engineer*
>
> *WSO2 Inc.*
>
> *Blog: http://manuriamayaperera.blogspot.com
> *
>



-- 

*Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
email: kasung AT spamfree wso2.com
linked-in: http://lk.linkedin.com/in/gajasinghe
blog: http://kasunbg.org
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] DSS Tryit Page issue

[Manuri Amaya Perera]

Hi all,

Please find the comments inline.

On Tue, Jun 21, 2016 at 9:48 AM, Anupama Pathirage  wrote:

> Hi,
>
> When we build the product DSS [1] with the latest Kernel Release (4.4.6),
> we have observed following issues in "Try it" page.  Appreciate any clue on
> this to get them resolved.
>
> *1) *In Https mode, Try it requests gives following error on send [2][3].
>
> WARN {org.owasp.csrfguard.log.JavaLogger} -  potential cross-site request
> forgery (CSRF) attack thwarted (user:, ip:10.100.7.118,
> method:POST, uri:/carbon/admin/jsp/WSRequestXSSproxy_ajaxprocessor.jsp,
> error:required token is missing from the request)
>
> Private proxy protocol will be attempted as cross-domain browser
> restrictions might be enforced for this endpoint.
>
> http://tryit.carbon.wso2.org;>
>Error connecting to the Tryit ajax proxy
> 
>
> *2)* Try it page does not load properly in Chrome. It loads correctly in
> Firefox. It gives the following error on chrome [4].
>
> Refused to execute script from '
> https://localhost:9443/services/echo?wsdl2form=editarea/edit_area_full.js'
> 
> because its MIME type ('text/html') is not executable, and strict MIME type
> checking is enabled.
> Uncaught ReferenceError: editAreaLoader is not defined.
>

​When downgrading DSS's kernel version to 4.4.5 this issue doesn't occur.
When comparing the response to the request
http://10.100.7.67:9783/services/echo?wsdl2form=editarea/edit_area_full.js
 in DSS with kernel 4.4.5 and kernel 4.4.6 it seems some additional headers
are present in the latter. They were,

   1. X-Content-Type-Options:
   nosniff
   2. X-Frame-Options:
   DENY
   3. X-XSS-Protection:
   1; mode=block

​Here the ​X-Content-Type-Options header is to make sure the browser does
not try to detect a different Content-Type than what is actually sent[1].
Here the content type of the response is
text/html
​.
​Therefore this error occurs for edit_area_full.js file. And it seems
firefox(at least the version we tested with) ​is not supporting this header
but chrome does[2], which should be the reason why we don't get this error
in firefox.

Anyway we built with kernel 4.4.6 and checked this in BPS and it seems
those additional headers are not present in the response.


[1] https://github.com/wso2/product-dss/
> [2] https://drive.google.com/open?id=0B16LG8jdYeP8ZEpyV1F5cmRsTDA
> [3] https://drive.google.com/open?id=0B16LG8jdYeP8LWF2elVTbzFQOWs
> [4] https://drive.google.com/open?id=0B16LG8jdYeP8VmtlWXEtdmRJUjQ
>
> Regards,
> --
> Anupama Pathirage
> Associate Technical Lead
> WSO2, Inc.  http://wso2.com/
> Email: anup...@wso2.com
> Mobile:+94 71 8273 979
>
>
>

​[1] https://www.owasp.org/index.php/REST_Security_Cheat_Sheet​
​[2]
http://stackoverflow.com/questions/18337630/what-is-x-content-type-options-nosniff​

​Thanks,
Manuri​

-- 

*Manuri Amaya Perera*

*Software Engineer*

*WSO2 Inc.*

*Blog: http://manuriamayaperera.blogspot.com
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] DSS Tryit Page issue

[Anupama Pathirage]

Hi,

When we build the product DSS [1] with the latest Kernel Release (4.4.6),
we have observed following issues in "Try it" page.  Appreciate any clue on
this to get them resolved.

*1) *In Https mode, Try it requests gives following error on send [2][3].

WARN {org.owasp.csrfguard.log.JavaLogger} -  potential cross-site request
forgery (CSRF) attack thwarted (user:, ip:10.100.7.118,
method:POST, uri:/carbon/admin/jsp/WSRequestXSSproxy_ajaxprocessor.jsp,
error:required token is missing from the request)

Private proxy protocol will be attempted as cross-domain browser
restrictions might be enforced for this endpoint.

http://tryit.carbon.wso2.org;>
   Error connecting to the Tryit ajax proxy


*2)* Try it page does not load properly in Chrome. It loads correctly in
Firefox. It gives the following error on chrome [4].

Refused to execute script from '
https://localhost:9443/services/echo?wsdl2form=editarea/edit_area_full.js'

because its MIME type ('text/html') is not executable, and strict MIME type
checking is enabled.
Uncaught ReferenceError: editAreaLoader is not defined.

[1] https://github.com/wso2/product-dss/
[2] https://drive.google.com/open?id=0B16LG8jdYeP8ZEpyV1F5cmRsTDA
[3] https://drive.google.com/open?id=0B16LG8jdYeP8LWF2elVTbzFQOWs
[4] https://drive.google.com/open?id=0B16LG8jdYeP8VmtlWXEtdmRJUjQ

Regards,
-- 
Anupama Pathirage
Associate Technical Lead
WSO2, Inc.  http://wso2.com/
Email: anup...@wso2.com
Mobile:+94 71 8273 979
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev