media_server

Files in the source code contain login credentials for the admin user and the property configuration password, allowing an attacker to get full access to the application.

The server supports authentication methods in which credentials are sent in plaintext over unencrypted channels. If an attacker were to intercept traffic between a client and this server, the credentials would be exposed.

All communication with the REST API is unencrypted (HTTP), allowing an attacker to intercept traffic between an actor and the webserver. This leads to the possibility of information gathering and downloading media files.

The application uses a weak password hash function, allowing an attacker to crack the weak password hash to gain access to an FTP user account.

The HttpOnlyflag of the session cookie \"@@\" is set to false. Since this flag helps preventing access to cookies via client-side scripts, setting the flag to false can lead to a higher possibility of Cross-Side-Scripting attacks which target the stored cookies.

The FTP server’s login mechanism does not restrict authentication attempts, allowing an attacker to brute-force user passwords and potentially compromising the FTP server.

The web application is vulnerable to clickjacking attacks. The site can be embedded into another frame, allowing an attacker to trick a user into clicking on something different from what the user perceives. This could potentially reveal confidential information or allow others to take control of their computer while clicking on seemingly innocuous objects.

The application fails to implement several security headers. These headers help increase the overall security level of the web application by e.g., preventing the application to be displayed in an iFrame (Clickjacking attacks) or not executing injected malicious JavaScript code (XSS attacks).

The Media Server’s authorization tokens have a poor quality of randomness. An attacker may be able to guess the token of an active user by computing plausible tokens.