AccessControl.Bypass: MooTools Authorization Bypass For Hidden Element
mahantsucf opened this issue · 1 comments
Stratos Version
Stratos Version 4.4.0
Frontend Deployment type
- Cloud Foundry Application (cf push)
- [X ] Kubernetes, using a helm chart
- Docker, single container deploying all components
- npm run start
- Other (please specify below)
Backend (Jet Stream) Deployment type
- Cloud Foundry Application (cf push)
- Kubernetes, using a helm chart
- Docker, single container deploying all components
- Other (please specify below)
Expected behaviour
When we do an AppScan static scan, the scanning results shouldn’t yield any vulnerabilities.
Actual behaviour
We ran Appscan and these vulnerabilities were marked as Medium Severity issues.
Steps to reproduce the behavior
AppScan Go: version 0.1.7
Steps
Open Appscan go application
Checkout the code of Stratos : release 4.4.0 (https://github.com/cloudfoundry/stratos.git) in your local machine.
Choose the type of scan i.e. Complete Security Scan
Click on Browse button and browse to the src folder(except test-e2e folder) of the stratos project that you checkout in step 2.
AppScan Go! retrieves appropriate files from the selected folder and lists them for review. No need to change anything on this just click on Continue button.
Click on Create a new scan button ---> Initiate scan : This will initiate the scan process.
When upload to AppScan on Cloud is complete, click the link review the status or results of the scan in the AppScan on Cloud service(there are lots of high severity issue you will see).
Reference : https://help.hcltechsw.com/appscan/ASoC/src_irx_gen_gui.html
Log output covering before error and any error statements
Detailed Description
Exact Location where the issue occurs:
src\frontend\packages\kubernetes\src\kubernetes\kube-config-registration\kube-config-selection\kube-config-selectio
n.component.ts:151
src\frontend\packages\kubernetes\src\kubernetes\kubernetes-resource-viewer\kubernetes-resource-viewer.compone
nt.ts:255
src\frontend\packages\kubernetes\src\kubernetes\workloads\release\helm-release-tab-base\helm-release-socket-ser
vice.ts:198
src\frontend\packages\kubernetes\src\kubernetes\workloads\release\helm-release-tab-base\helm-release-tab-base.c
omponent.ts:75
src\frontend\packages\kubernetes\src\kubernetes\workloads\release\tabs\helm-release-summary-tab\helm-release-s
ummary-tab.component.ts:236
src\frontend\packages\core\src\features\endpoints\endpoints-page\endpoints-page.component.ts:120
src\frontend\packages\core\src\shared\services\side-panel.service.ts:112
src\frontend\packages\core\src\shared\services\side-panel.service.ts:141
src\frontend\packages\core\src\features\dashboard\dashboard-base\dashboard-base.component.ts:129
Context
Risk
Attackers can issue a request directly to a page or resource that they may not be authorized to access, allowing an attacker to gain
access to sensitive information, or possibly even corrupt resources and information.
Cause
The access policy to application functionality is not consistently enforced on every resource request, and access to resources is not
restricted to authorized users only.
Effectively the application grants more permissions than required, or conversely, does not correctly apply restrictions on what actions
the user can perform.
Possible Implementation
Ensure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access
any information that they are not authorized for by simply requesting direct access to that page.
Ensure that all pages that contains sensitive information or functionality, restrict access to requests that are accompanied by an active
and authenticated session token associated with a user who has the required permissions to access that page.
Only grant the privileges that are necessary for required business functionality, according to the principle of Least Privilege.
We found this is false positive issue , Hence closing.