SRS - Fortify Security Report
SRS - Fortify Security Report
Executive Summary
Issues Overview
On Sep 24, 2024, a source code review was performed over the SRS code base. 2,452 files, 192,549 LOC (Executable) were
scanned and reviewed for defects that could lead to potential security vulnerabilities. A total of 48 reviewed findings were
uncovered during the analysis.
Project Summary
Code Base Summary
Code location:
Number of Files: 2452
Lines of Code: 192549
Build Label: <No Build Label>
Scan Information
Scan time: 02:12:27
SCA Engine version: 20.2.2.0003
Machine Name: HDQCP30860
Username running scan: 637922
Results Certification
Results Certification Valid
Details:
Results Signature:
Rules Signature:
Attack Surface
Attack Surface:
Private Information:
null.null.null
null.null.null
System Information:
null.null.null
Web:
null.null.null
Folder Filters:
If [fortify priority order] contains critical Then set folder to Critical
If [fortify priority order] contains high Then set folder to High
Results Outline
Overall number of results
The scan found 48 issues.
Number of Issues
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
<Unaudited>
Not an Issue
Reliability Issue
Bad Practice
Suspicious
Exploitable
Abstract:
Storing a plain text password in a configuration file may result in a system compromise.
Explanation:
Storing a plain text password in a configuration file allows anyone who can read the file access to the password-protected
resource. Developers sometimes believe that they cannot defend the application from someone who has access to the
configuration, but this attitude makes an attacker's job easier. Good password management guidelines require that a password
never be stored in plain text.
Recommendations:
A password should never be stored in plain text. An administrator should be required to enter the password when the system
starts. If that approach is impractical, a less secure but often adequate solution is to obfuscate the password and scatter the de-
obfuscation material around the system so that an attacker has to obtain and correctly combine multiple system resources to
decipher the password.
Some third-party products claim the ability to manage passwords in a more secure way. For example, WebSphere Application
Server 4.x uses a simple XOR encryption algorithm for obfuscating values, but be skeptical about such facilities. WebSphere and
other application servers offer outdated and relatively weak encryption mechanisms that are insufficient for security-sensitive
environments. For a secure solution the only viable option is a proprietary one.
Tips:
1. Fortify Static Code Analyzer searches configuration files for common names used for password properties. Audit these issues
by verifying that the flagged entry is used as a password and that the password entry contains plain text.
2. If the entry in the configuration file is a default password, require that it be changed in addition to requiring that it be
obfuscated in the configuration file.
Number of Issues
0 1 2 3 4 5 6 7 8 9
<Unaudited>
Not an Issue
Reliability Issue
Bad Practice
Suspicious
Exploitable
Abstract:
The application is configured to communicate with its database server in plain text over unencrypted channels, making the
communicated data vulnerable to interception via man-in-the-middle (MiTM) attacks.
Explanation:
The application communicates with its database server over unencrypted channels and may pose a significant security risk to the
company and users of that application. In this case, an attacker can modify the user entered data or even execute arbitrary SQL
commands against the database server.
Example 1: The following configuration causes the application to communicate with its database server over unencrypted
channels:
<connectionStrings>
<add name="Test" connectionString="Data Source=210.10.20.10,1433; Initial Catalog=myDataBase;User
ID=myUsername;Password=myPassword;" providerName="System.Data.SqlClient" />
</connectionStrings>
Recommendations:
Most database servers offer encrypted alternatives on different ports that use SSL/TLS to encrypt all the data being sent over the
wire. Always use these alternatives when possible.
Example 2: The following configuration causes the application to communicate with its database server over encrypted channels:
<connectionStrings>
<add name="Test" connectionString="Data Source=210.10.20.10,1433; Initial Catalog=myDataBase;User
ID=myUsername;Password=myPassword; Encrypt=yes;" providerName="System.Data.SqlClient" />
</connectionStrings>
Number of Issues
0 1 2 3 4 5
<Unaudited>
Not an Issue
Reliability Issue
Bad Practice
Suspicious
Exploitable
Abstract:
The application session cookie is created without the Secure flag set to true.
Explanation:
Modern web browsers support a Secure flag for each cookie. If the flag is set, the browser will only send the cookie over HTTPS.
Sending cookies over an unencrypted channel can expose them to network sniffing attacks, so the secure flag helps keep a
cookie's value confidential. This is especially important if the cookie contains private data or carries a session identifier.
Example 1: A configuration that results in the session cookie being added to the response without setting the Secure flag.
...
<configuration>
<system.web>
<authentication mode="Forms">
<forms requireSSL="false" loginUrl="login.aspx">
</forms>
</authentication>
</system.web>
</configuration>
...
If your application uses both HTTPS and HTTP but does not set the Secure flag, cookies sent during an HTTPS request will also
be sent during subsequent HTTP requests. Sniffing network traffic over unencrypted wireless connections is a trivial task for
attackers, so sending cookies (especially those with session IDs) over HTTP can result in application compromise.
Recommendations:
Set the Secure flag on all new cookies in order to instruct browsers not to send these cookies in the clear.
Example 2: The following configuration specifies requireSSL="true" to ensure the Secure flag is set on cookies.
...
<configuration>
<system.web>
<authentication mode="Forms">
<forms requireSSL="true" loginUrl="login.aspx">
</forms>
</authentication>
</system.web>
</configuration>
...
SRS.dll.config, line 112 (Cookie Security: Session Cookie not Sent Over SSL)
Fortify Priority: High Folder High
Kingdom: Security Features
Abstract: The application session cookie is created without the Secure flag set to true.
Number of Issues
0 1 2 3
<Unaudited>
Not an Issue
Reliability Issue
Bad Practice
Suspicious
Exploitable
Abstract:
Using an empty string as a password is insecure.
Explanation:
It is never appropriate to use an empty string as a password. It is too easy to guess.
Recommendations:
Require that sufficiently hard-to-guess passwords protect all accounts and system resources. Consult the references to help
establish appropriate password guidelines.
Tips:
1. Fortify Static Code Analyzer searches configuration files for common names used for password properties. Audit these issues
by verifying that the flagged entry is used as a password.
<none>