A vulnerability: HTML form without CSRF protection was found.
Scanner: ACUNETIX
Asset Information
Asset name:
IP: 6
URL Path:
Recommended fix: Verify if this form requires anti-CSRF protection and implement CSRF countermeasures if necessary.
The recommended and the most widely used technique for preventing CSRF attacks is know as an anti-CSRF token, also sometimes referred to as a synchronizer token. The characteristics of a well designed anti-CSRF system involve the following attributes.
The anti-CSRF token should be unique for each user session
The session should automatically expire after a suitable amount of time
The anti-CSRF token should be a cryptographically random value of significant length
The anti-CSRF token should be cryptographically secure, that is, generated by a strong Pseudo-Random Number Generator (PRNG) algorithm
The anti-CSRF token is added as a hidden field for forms, or within URLs (only necessary if GET requests cause state changes, that is, GET requests are not idempotent)
The server should reject the requested action if the anti-CSRF token fails validation
When a user submits a form or makes some other authenticated request that requires a Cookie, the anti-CSRF token should be included in the request. Then, the web application will then verify the existence and correctness of this token before processing the request. If the token is missing or incorrect, the request can be rejected.
Please see https://192.168.2.250/nucleus/public/app/index.html for more information on these vulnerabilities
A vulnerability: HTML form without CSRF protection was found. Scanner: ACUNETIX Asset Information Asset name: IP: 6 URL Path: Recommended fix: Verify if this form requires anti-CSRF protection and implement CSRF countermeasures if necessary. The recommended and the most widely used technique for preventing CSRF attacks is know as an anti-CSRF token, also sometimes referred to as a synchronizer token. The characteristics of a well designed anti-CSRF system involve the following attributes.
The anti-CSRF token should be unique for each user session The session should automatically expire after a suitable amount of time The anti-CSRF token should be a cryptographically random value of significant length The anti-CSRF token should be cryptographically secure, that is, generated by a strong Pseudo-Random Number Generator (PRNG) algorithm The anti-CSRF token is added as a hidden field for forms, or within URLs (only necessary if GET requests cause state changes, that is, GET requests are not idempotent) The server should reject the requested action if the anti-CSRF token fails validation
When a user submits a form or makes some other authenticated request that requires a Cookie, the anti-CSRF token should be included in the request. Then, the web application will then verify the existence and correctness of this token before processing the request. If the token is missing or incorrect, the request can be rejected. Please see https://192.168.2.250/nucleus/public/app/index.html for more information on these vulnerabilities