Cross-Site Request Forgery 
In the majority of today’s web applications, clients are required to submit forms which can perform sensitive operations.

An example of such a form being used would be when an administrator wishes to create a new user for the application.

In the simplest version of the form, the administrator would fill-in:

Name
Password
Role (level of access)
Continuing with this example, Cross Site Request Forgery (CSRF) would occur when the administrator is tricked into clicking on a link, which if logged into the application, would automatically submit the form without any further interaction.

Cyber-criminals will look for sites where sensitive functions are performed in this manner and then craft malicious requests that will be used against clients via a social engineering attack.

There are 3 things that are required for a CSRF attack to occur:

The form must perform some sort of sensitive action.
The victim (the administrator the example above) must have an active session.
Most importantly, all parameter values must be known or guessable.
 It was discovered that all parameters within the form were known or predictable and therefore the form could be vulnerable to CSRF.

http://cwe.mitre.org/data/definitions/352.html
URL /login/index.php

Missing 'Strict-Transport-Security' header

The HTTP protocol by itself is clear text, meaning that any data that is transmitted via HTTP can be captured and the contents viewed. To keep data private and prevent it from being intercepted, HTTP is often tunnelled through either Secure Sockets Layer (SSL) or Transport Layer Security (TLS). When either of these encryption standards are used, it is referred to as HTTPS.

HTTP Strict Transport Security (HSTS) is an optional response header that can be configured on the server to instruct the browser to only communicate via HTTPS. This will be enforced by the browser even if the user requests a HTTP resource on the same server.

Cyber-criminals will often attempt to compromise sensitive information passed from the client to the server using HTTP. This can be conducted via various Man-in-The-Middle (MiTM) attacks or through network packet captures.
It was discovered that the affected application is using HTTPS however does not use the HSTS header.

http://cwe.mitre.org/data/definitions/200.html

Backup directory

A common practice when administering web applications is to create a copy/backup of a particular directory prior to making any modification. Another common practice is to add an extension or change the name of the original directory to signify that it is a backup (examples include .bak, .orig, .backup, etc.).

During the initial recon stages of an attack, cyber-criminals will attempt to locate backup directories by adding common extensions onto directories already discovered on the webserver. By analyzing the response headers from the server they are able to determine if a backup directory exists. These backup directories can then assist in the compromise of the web application.

By utilizing the same method, It was discovered a possible backup directory

http://cwe.mitre.org/data/definitions/530.html

URLS:  /system/jquery.centova.password.js.gz  /system/res.common.js.gz /system/res.common.js.gz /system/jquery.centova.password.css.gz  /system/jquery.centova.password.css.gz

Missing 'X-Frame-Options' header

Clickjacking (User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a Web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages.

The server didn’t return an X-Frame-Options header which means that this website could be at risk of a clickjacking attack.

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page inside a frame or iframe. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.

http://cwe.mitre.org/data/definitions/693.html

Password field with auto-complete
In typical form-based web applications, it is common practice for developers to allow autocomplete within the HTML form to improve the usability of the page. With autocomplete enabled (default), the browser is allowed to cache previously entered form values.

For legitimate purposes, this allows the user to quickly re-enter the same data when completing the form multiple times.

When autocomplete is enabled on either/both the username and password fields, this could allow a cyber-criminal with access to the victim’s computer the ability to have the victim’s credentials automatically entered as the cyber-criminal visits the affected page.

It was discovered that the affected page contains a form containing a password field that has not disabled autocomplete.

https://cwe.mitre.org/data/definitions/200.html

Insecure cookies
HTTP by itself is a stateless protocol. Therefore the server is unable to determine which requests are performed by which client, and which clients are authenticated or unauthenticated.

The use of HTTP cookies within the headers, allows a web server to identify each individual client and can therefore determine which clients hold valid authentication, from those that do not. These are known as session cookies.

When a cookie is set by the server (sent the header of an HTTP response) there are several flags that can be set to configure the properties of the cookie and how it is to be handled by the browser.

One of these flags is known as the secure flag. When the secure flag is set, the browser will prevent it from being sent over a clear text channel (HTTP) and only allow it to be sent when an encrypted channel is used (HTTPS).

it was  discovered that  cookies were set by the server without the secure flag being set. Although the initial setting of this cookie was via an HTTPS connection, any HTTP link to the same server will result in the cookie being send in clear text.

https://cwe.mitre.org/data/definitions/200.html

HttpOnly cookies

When a cookie is set by the server (sent the header of an HTTP response) there are several flags that can be set to configure the properties of the cookie and how it is to be handled by the browser.

The HttpOnly flag assists in the prevention of client side-scripts (such as JavaScript) accessing and using the cookie.

This can help prevent XSS attacks targeting the cookies holding the client’s session token (setting the HttpOnly flag does not prevent, nor safeguard against XSS vulnerabilities themselves).

https://cwe.mitre.org/data/definitions/200.html