[jira] [Resolved] (CONNECTORS-1597) reflected cross-site scripting vulnerability

2020-02-03 Thread Karl Wright (Jira)


 [ 
https://issues.apache.org/jira/browse/CONNECTORS-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Wright resolved CONNECTORS-1597.
-
Fix Version/s: ManifoldCF 2.13
   Resolution: Fixed

> reflected cross-site scripting vulnerability
> 
>
> Key: CONNECTORS-1597
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1597
> Project: ManifoldCF
>  Issue Type: Improvement
>  Components: API
>Affects Versions: ManifoldCF 2.12
>Reporter: roel goovaerts
>Assignee: Kishore Kumar
>Priority: Minor
> Fix For: ManifoldCF 2.13
>
>
> This is the full report of a penetration test, performed at a client where we 
> deployed a system which uses manifold:
> *Summary*
> A reflected cross-site scripting vulnerability was discovered in the 
> application.
> Reflected cross-site scripting occurs when a web application displays data 
> submitted by the user that
> contains HTML markup and scripting code without properly escaping it. An 
> attacker will create a link to the
> vulnerable page that will display JavaScript code crated by the attacker. The 
> attacker will then trick an
> authenticated application user into clicking or following this crated link. 
> When the user's browser parses the
> generated page, it will execute the code crafted by the attacker. If the user 
> was logged in to the application
> when he followed the link, the attacker's code could perform any action in 
> the application that the user can
> perform.
> *Impact*
> Reflected cross-site scripting can be used by attackers to compromise the 
> session of an authenticated user.
> By persuading the victim to click on a specially crafted link, the attacker 
> can execute his own JavaScript
> payload in the browser context of the victim. In this specific case, an 
> attacker could hijack its victim's session
> given that the session token is not flagged as HttpOnly as demonstrated in 
> [G190204T1F4][MANIFOLD]
> Insecure Cookie Configuration.
> Additional attacks exist where an attacker can deceive end users of the 
> application by redirecting them to
> replica sites or trick them into downloading trojans or other malware. The 
> attacker can also use a so called
> browser exploitation framework. In this scenario the attacker injects 
> JavaScript code that communicates to
> the attack framework running on the attacker's computer. When the victim user 
> executes the JavaScript code
> the attacker can control the victim's browser. Publicly available frameworks 
> exist (BeEF -
> [http://www.bindshell.net/tools/beef], Backframe 
> -[http://www.gnucitizen.org/projects/backframe/], XSS Proxy -
> [http://xss-proxy.sourceforge.net/]).
> *Affected Systems*
>  * [https://els-manifold-uat.bc:8475/mcf-crawler-ui/] [name of an arbitrarily 
> supplied URL parameter]
> *Description*
> A case where the application includes user input into the generated HTML 
> pages without properly escaping
> the user supplied data was discovered in the application. The HTTP requests 
> and responses shown below
> demonstrate the problem.
> {code:java}
> GET /mcf-crawler-ui/?smafi">alert(1)non7x=1 HTTP/1.1
> Host: els-manifold-uat.bc:8475
> Accept-Encoding: gzip, deflate
> Accept: */*
> Accept-Language: en
> User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; 
> Trident/5.0)
> Connection: close
> Cookie: JSESSIONID=ov3qae9biucxdat0xiin5s18
> {code}
> {code:java}
> HTTP/1.1 200 OK
> Server: nginx/1.12.2
> Date: Mon, 18 Feb 2019 13:07:02 GMT
> Content-Type: text/html;charset=utf-8
> Content-Length: 2576
> Connection: close
> Pragma: No-cache
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
> Cache-Control: no-cache
> max-age: Thu, 01 Jan 1970 00:00:00 GMT
> 
> 
> 
> http://www.w3.org/1999/xhtml;>
> 
> 
> 
> 
>  type="text/css"/>
> 
> Apache ManifoldCF™ Login
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Sign in to start your session
>  method="POST">
> alert(1)non7x=1">
> 
> --snip--
> {code}
> *Recommendations*
> We recommend that the application enforces proper validation on user input. 
> In most situations where usercontrollable
> data is copied into application responses, cross-site scripting attacks can 
> be prevented using two
> layers of defenses:
>  * Input should be validated as strictly as possible on arrival, given the 
> kind of content which it is
> expected to contain. For example, personal names should consist of 
> alphabetical and a small range
> of typographical characters, and be relatively short; a year of birth should 
> consist of exactly 

[jira] [Commented] (CONNECTORS-1597) reflected cross-site scripting vulnerability

2020-02-03 Thread Karl Wright (Jira)


[ 
https://issues.apache.org/jira/browse/CONNECTORS-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028833#comment-17028833
 ] 

Karl Wright commented on CONNECTORS-1597:
-

Final analysis of this ticket is that, since ManifoldCF's UI does not have 
different classes of users, and since we've already dealt with any problems 
with the login page, escalation of privileges is not a valid attack vector 
against the ManifoldCF UI.


> reflected cross-site scripting vulnerability
> 
>
> Key: CONNECTORS-1597
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1597
> Project: ManifoldCF
>  Issue Type: Improvement
>  Components: API
>Affects Versions: ManifoldCF 2.12
>Reporter: roel goovaerts
>Assignee: Kishore Kumar
>Priority: Minor
>
> This is the full report of a penetration test, performed at a client where we 
> deployed a system which uses manifold:
> *Summary*
> A reflected cross-site scripting vulnerability was discovered in the 
> application.
> Reflected cross-site scripting occurs when a web application displays data 
> submitted by the user that
> contains HTML markup and scripting code without properly escaping it. An 
> attacker will create a link to the
> vulnerable page that will display JavaScript code crated by the attacker. The 
> attacker will then trick an
> authenticated application user into clicking or following this crated link. 
> When the user's browser parses the
> generated page, it will execute the code crafted by the attacker. If the user 
> was logged in to the application
> when he followed the link, the attacker's code could perform any action in 
> the application that the user can
> perform.
> *Impact*
> Reflected cross-site scripting can be used by attackers to compromise the 
> session of an authenticated user.
> By persuading the victim to click on a specially crafted link, the attacker 
> can execute his own JavaScript
> payload in the browser context of the victim. In this specific case, an 
> attacker could hijack its victim's session
> given that the session token is not flagged as HttpOnly as demonstrated in 
> [G190204T1F4][MANIFOLD]
> Insecure Cookie Configuration.
> Additional attacks exist where an attacker can deceive end users of the 
> application by redirecting them to
> replica sites or trick them into downloading trojans or other malware. The 
> attacker can also use a so called
> browser exploitation framework. In this scenario the attacker injects 
> JavaScript code that communicates to
> the attack framework running on the attacker's computer. When the victim user 
> executes the JavaScript code
> the attacker can control the victim's browser. Publicly available frameworks 
> exist (BeEF -
> [http://www.bindshell.net/tools/beef], Backframe 
> -[http://www.gnucitizen.org/projects/backframe/], XSS Proxy -
> [http://xss-proxy.sourceforge.net/]).
> *Affected Systems*
>  * [https://els-manifold-uat.bc:8475/mcf-crawler-ui/] [name of an arbitrarily 
> supplied URL parameter]
> *Description*
> A case where the application includes user input into the generated HTML 
> pages without properly escaping
> the user supplied data was discovered in the application. The HTTP requests 
> and responses shown below
> demonstrate the problem.
> {code:java}
> GET /mcf-crawler-ui/?smafi">alert(1)non7x=1 HTTP/1.1
> Host: els-manifold-uat.bc:8475
> Accept-Encoding: gzip, deflate
> Accept: */*
> Accept-Language: en
> User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; 
> Trident/5.0)
> Connection: close
> Cookie: JSESSIONID=ov3qae9biucxdat0xiin5s18
> {code}
> {code:java}
> HTTP/1.1 200 OK
> Server: nginx/1.12.2
> Date: Mon, 18 Feb 2019 13:07:02 GMT
> Content-Type: text/html;charset=utf-8
> Content-Length: 2576
> Connection: close
> Pragma: No-cache
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
> Cache-Control: no-cache
> max-age: Thu, 01 Jan 1970 00:00:00 GMT
> 
> 
> 
> http://www.w3.org/1999/xhtml;>
> 
> 
> 
> 
>  type="text/css"/>
> 
> Apache ManifoldCF™ Login
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Sign in to start your session
>  method="POST">
> alert(1)non7x=1">
> 
> --snip--
> {code}
> *Recommendations*
> We recommend that the application enforces proper validation on user input. 
> In most situations where usercontrollable
> data is copied into application responses, cross-site scripting attacks can 
> be prevented using two
> layers of defenses:
>  * Input should be validated as strictly as possible on arrival, given the 
> kind of content which it is
> expected 

[jira] [Resolved] (CONNECTORS-1595) cross-site request forgery vulnerability

2020-02-03 Thread Karl Wright (Jira)


 [ 
https://issues.apache.org/jira/browse/CONNECTORS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Wright resolved CONNECTORS-1595.
-
Resolution: Not A Problem

> cross-site request forgery vulnerability
> 
>
> Key: CONNECTORS-1595
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1595
> Project: ManifoldCF
>  Issue Type: Improvement
>  Components: API
>Affects Versions: ManifoldCF 2.12
>Reporter: roel goovaerts
>Assignee: Kishore Kumar
>Priority: Minor
>
> Below is the full analysis and description as a result from the penetration 
> test.
> *Summary*
> The application is vulnerable to Cross-Site Request Forgery (CSRF).
> A cross-site request forgery attack uses the following scenario:
> 1. An attacker creates a web page that includes an image or a form pointing 
> to the attacked application.
> The image source would actually be a URL with parameters pointing to the 
> application page that
> performs some action. In case of a form, the form action would point to the 
> action page in the target
> application, and the form is submitted automatically by JavaScript when the 
> page is viewed.
> 2. The attacker tricks the victim user to browse to this page. The attacker 
> may get the victim to click a
> link, or embed the attacking HTML code into some page the victim views, for 
> example in a bulletin
> board or chat.
> 3. When the victim views the attacker's page, his browser sends a request 
> prepared by the attacker to
> the attacked application. If the victim is logged in to the target 
> application, his browser will possess
> all necessary session tokens, so the request will appear as authorized to the 
> application and
> succeed.
> A cross-site request forgery attack uses the fact that the victim's browser 
> possesses the necessary
> authentication tokens to perform some actions in the target application.
> *Impact*
> A remote, unauthenticated attacker that can trick an authenticated user into 
> clicking a link crafted by the
> attacker or open a malicious web page, can force the victim to unknowingly 
> perform various actions within
> the application.
> Given that the whole application is not protected against CSRF, any action 
> that an administrator can take on
> Apache Manifold could be unknowingly performed if they fall for a CSRF attack.
> *Affected Systems*
>  * [https://els-manifold-uat.bc:8475/mcf-crawler-ui/]
> *Description*
> It appears that the application does not implement any CSRF protection. 
> Consider the following example. An
> attacker tricks a logged in application user to visit a page containing the 
> following code:
> {code:java}
> 
> 
> 
> history.pushState('', '', '/')
> https://els-manifold-uat.bc:8475/mcf-crawler-ui/execute.jsp;
> method="POST" enctype="multipart/form-data">
> 
> 
> 
> 
> 
> 
>  value="orgapachemanifoldcfcrawlerconnectorswebcrawlerWebcr
> awlerConnector" />
> 
> 
> 
>  value="ferdiklompcraftworkznl" />
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  value="httpsintrauatwebbc" />
>  />
> 
>  value="validation" />
>  value=""
> />
>  value="Continue" />
>  value="username" />
>  value="id996812" />
>  value="" />
>  value="Continue" />
>  value="password" />
>  value="Th1sIs4cl1X" />
>  value="" />
>  value="Continue" />
>  value="loginformtype" />
>  value="pwd" />
>  value="" />
>  value="3" />
> 
> 
>  value="httpsintrauatwebbc" />
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> When the victim's browser parses the page and tries to load images, it will 
> cause them to execute any action
> of the attacker's choosing on Manifold.
> *Recommendations*
> The usual approach to preventing CSRF attacks is to add a new parameter with 
> an unpredictable value to
> each form or link that performs some action in the application, commonly 
> referred to as a CSRF-Token. The
> parameter value should have enough entropy so that it cannot be predicted by 
> an attacker and should be
> unique to the current user session. When the user submits the form or clicks 
> the link, the server side code
> checks the parameter value. If it is valid, the request is accepted, 
> otherwise it is denied. The attacker has no
> way of knowing the value of the unpredictable parameter, so he cannot 
> construct a form or link that will
> submit a valid request.
> *References*
>  * OWASP - Cross-Site Request Forgery - 
> [https://www.owasp.org/index.php/Cross-]
> Site_Request_Forgery



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (CONNECTORS-1595) cross-site request forgery vulnerability

2020-02-03 Thread Karl Wright (Jira)


[ 
https://issues.apache.org/jira/browse/CONNECTORS-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17028832#comment-17028832
 ] 

Karl Wright commented on CONNECTORS-1595:
-

Note: the team here did analyze this potential attack vector, noting the 
following:

(1) The UI does not have different capabilities for individual users.  The only 
security is whether you are "in" or not.
(2) The attack described in this ticket does not get an attacker "in", it just 
gives them capabilities once they do that that they might not have.   But since 
all users are created equally in the MCF UI, this is not problematic.


> cross-site request forgery vulnerability
> 
>
> Key: CONNECTORS-1595
> URL: https://issues.apache.org/jira/browse/CONNECTORS-1595
> Project: ManifoldCF
>  Issue Type: Improvement
>  Components: API
>Affects Versions: ManifoldCF 2.12
>Reporter: roel goovaerts
>Assignee: Kishore Kumar
>Priority: Minor
>
> Below is the full analysis and description as a result from the penetration 
> test.
> *Summary*
> The application is vulnerable to Cross-Site Request Forgery (CSRF).
> A cross-site request forgery attack uses the following scenario:
> 1. An attacker creates a web page that includes an image or a form pointing 
> to the attacked application.
> The image source would actually be a URL with parameters pointing to the 
> application page that
> performs some action. In case of a form, the form action would point to the 
> action page in the target
> application, and the form is submitted automatically by JavaScript when the 
> page is viewed.
> 2. The attacker tricks the victim user to browse to this page. The attacker 
> may get the victim to click a
> link, or embed the attacking HTML code into some page the victim views, for 
> example in a bulletin
> board or chat.
> 3. When the victim views the attacker's page, his browser sends a request 
> prepared by the attacker to
> the attacked application. If the victim is logged in to the target 
> application, his browser will possess
> all necessary session tokens, so the request will appear as authorized to the 
> application and
> succeed.
> A cross-site request forgery attack uses the fact that the victim's browser 
> possesses the necessary
> authentication tokens to perform some actions in the target application.
> *Impact*
> A remote, unauthenticated attacker that can trick an authenticated user into 
> clicking a link crafted by the
> attacker or open a malicious web page, can force the victim to unknowingly 
> perform various actions within
> the application.
> Given that the whole application is not protected against CSRF, any action 
> that an administrator can take on
> Apache Manifold could be unknowingly performed if they fall for a CSRF attack.
> *Affected Systems*
>  * [https://els-manifold-uat.bc:8475/mcf-crawler-ui/]
> *Description*
> It appears that the application does not implement any CSRF protection. 
> Consider the following example. An
> attacker tricks a logged in application user to visit a page containing the 
> following code:
> {code:java}
> 
> 
> 
> history.pushState('', '', '/')
> https://els-manifold-uat.bc:8475/mcf-crawler-ui/execute.jsp;
> method="POST" enctype="multipart/form-data">
> 
> 
> 
> 
> 
> 
>  value="orgapachemanifoldcfcrawlerconnectorswebcrawlerWebcr
> awlerConnector" />
> 
> 
> 
>  value="ferdiklompcraftworkznl" />
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  value="httpsintrauatwebbc" />
>  />
> 
>  value="validation" />
>  value=""
> />
>  value="Continue" />
>  value="username" />
>  value="id996812" />
>  value="" />
>  value="Continue" />
>  value="password" />
>  value="Th1sIs4cl1X" />
>  value="" />
>  value="Continue" />
>  value="loginformtype" />
>  value="pwd" />
>  value="" />
>  value="3" />
> 
> 
>  value="httpsintrauatwebbc" />
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> When the victim's browser parses the page and tries to load images, it will 
> cause them to execute any action
> of the attacker's choosing on Manifold.
> *Recommendations*
> The usual approach to preventing CSRF attacks is to add a new parameter with 
> an unpredictable value to
> each form or link that performs some action in the application, commonly 
> referred to as a CSRF-Token. The
> parameter value should have enough entropy so that it cannot be predicted by 
> an attacker and should be
> unique to the current user session. When the user submits the form or clicks 
> the link, the server side code
> checks the parameter value. If it is valid, the request is accepted, 
> otherwise it is denied. The attacker has no
> way of knowing the value of the unpredictable parameter, so he cannot 
> construct a form or link that will
> submit a valid request.
> *References*
>  * OWASP - Cross-Site Request Forgery - 
>