Avatar of bduhaish
bduhaish
Flag for Saudi Arabia asked on

Vulnerability findings by Rational Appscan on Authentication Credentials using .Net Language

Hello Experts,

Our Security team is using Rational Appscan software for scanning applications from any kind of Vulnerability’s and sensitive information’s that may allow malicious users to obtain. However, the result I get from the software is classified under three categories:

Authentication.Credentials.Unprotected
Authentication.Credentials.Weak
Injection.DBConnectionString

Theses Vulnerabilities or categories are pointed to line number 2  as follow:
Sub Read()
        Using connection As New SqlConnection(ConfigurationManager.ConnectionStrings("LocalSqlServer").ToString())
            Const queryString As String = "SELECT Name from Users where SAPID = @SAPID"
            Dim command As New SqlCommand(queryString, connection)
            Dim parUsername As New SqlParameter("@SAPID", SqlDbType.VarChar, 20)
            parUsername.Value = TextBox1.Text
            command.Parameters.Add(parUsername)
            command.Connection.Open()
            Using reader As SqlDataReader = command.ExecuteReader(CommandBehavior.CloseConnection)
                ' Call Read before accessing data.
                If reader.HasRows Then
                    While reader.Read()
                        Label1.Text = reader("Name")
                    End While
                End If
            End Using
        End Using
    End Sub

Open in new window

The connection string in the web.config file is encrypted using RSA with a Machine-Level Key Container.

The connection string before it is encrypted is as as follow:
<connectionStrings>
  <add name="LocalSqlServer" 
      connectionString=";Database=;User ID=;Password=;Trusted_Connection=False;"/>
</connectionStrings>

Open in new window

Can someone tell me whey the SQL statement above is Vulnerable.

Thanks.
Vulnerabilities.NET ProgrammingASP.NET

Avatar of undefined
Last Comment
btan

8/22/2022 - Mon
Kyle Abrahams

What if textbox1.Text  =

''; select * from users
bduhaish

ASKER
nothing will happen.
ASKER CERTIFIED SOLUTION
btan

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
GET A PERSONALIZED SOLUTION
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.
bduhaish

ASKER
Hello breadtan,

All what you mentioned is considered,

Again, whay this software known by IBM is telling me that this subroutine is Vulnerable !!!

The Classification is type 2 and the Severity is High.

All three vulnerability’s are pointing to the below line.

Authentication.Credentials.Unprotected
Authentication.Credentials.Weak
Injection.DBConnectionString

Using connection As New SqlConnection(ConfigurationManager.ConnectionStrings("LocalSqlServer").ToString())

Open in new window

Thanks.
Experts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes
Rich Rumble

Typically Appscan give you a URL or a string to show you the exploit it tried and found. This isn't always the case, but more often than not it's in the report. Sometimes there are false positives, you have to test the string it used, look in your logs or your DB to see if it did work.
The authentication weaknesses could be plain-text cookies, or perhaps base64 credentials, or a cipher/implementation that has poor entropy (like DES or 56-bit RSA etc) The report should give you links to the answers your looking for.
-rich
Kamal Khaleefa

placing the connection string in web.config is not recommended but since you are encrypting it then it seems ok

try to move your connection string into your classes also make validation on every text box to prevent special charachters
btan

As highlighted by experts in this discussion, the scanner would have a recommendation list  (e.g. Advisory, Fix Recommendation, Request/Response)stated to correspond to the findings. Also in various programming languages.  It should not be far off with what was already stated in the links in my last posting esp those from owasp and msdn. I see the key is that there are needs to have input type validation beside just key length restriction on the parameter in your existing code.

Even IBM has similar recommendation

http://publib.boulder.ibm.com/infocenter/spssdc/v6r0m1/index.jsp?topic=%2Fcom.spss.ddl%2Fsecure_dc_website.htm

As for weak authentication and unprotected parameter, that depends on how those parameters are secure at rest and in channel. The recommendation in the summary finding rightfully should have it too.
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
bduhaish

ASKER
Thank you all for your answers.
As I mentioned before that it is a connection string issue and not parameters or SQL Injections. Now, because we just lunched this software, only view employees have license, me and others are waiting for something called flouting license. However, as requested I managed to get a report from the security group that explains the findings along with a report for the lines in aspx page.
The report is telling us to use SqlConnectionStringBuilder class.
OK, I heard about this class since .Net 2.0, but never used it before so I did my workaround and I end up with same result, I will show exactly what I did in details :
 
In Configuration File
<configuration>
   <connectionStrings>
  <add name="conStr" 
    connectionString="Persist Security Info=False;User ID=AAAAAAA;Password=*******;Initial Catalog=XXXXXXX;Server=ZZZZZZZZZ" />
</connectionStrings>

<system.web>
<authentication mode="Windows"/>
		<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider"/>
		<authorization>
			<allow roles="Domain\Group"/>
			<deny users="?"/>
			<deny users="*"/>
		</authorization>
		<customErrors mode="Off"/>
</system.web>

Open in new window

After Encrypting.
<configuration>
   <configProtectedData>
      <providers>
   <!-- contents -->
      </providers>
</configProtectedData>

<connectionStrings configProtectionProvider="CustomProvider">
  <EncryptedData>
    <!-- encrypted contents -->
  </EncryptedData>
</connectionStrings>

Open in new window

I then create a class file "Connections.vb" to create the connection.
Imports System.Configuration
Imports System.Data.SqlClient

Public Class Connections
    Shared sqlClient As String = ConfigurationManager.ConnectionStrings("conStr").ConnectionString
    Shared sqlConn As String = Nothing
    Shared builderStr As SqlConnectionStringBuilder = Nothing
    Shared connStr As SqlConnection = Nothing

    Public Shared Function [get]() As SqlConnection
        If sqlConn Is Nothing Then
            sqlConn = sqlClient
            builderStr = New SqlConnectionStringBuilder(sqlConn.ToString) -- line 22
            connStr = New SqlConnection(builderStr.ConnectionString) -- line 23
        End If
        Return connStr
    End Function
End Class

Open in new window


Then in my aspx file i called the connection as follow:
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        Const sqlQuery As String = "select * from users"

        Using command As New SqlCommand(sqlQuery, Connections.[get]())
            Connections.get.Open()
            Dim sqlda As New SqlDataAdapter(command)
            Dim ds As New DataSet()
            sqlda.SelectCommand = command
            sqlda.Fill(ds, "users")
            GridView1.DataSource = ds
            GridView1.DataMember = "users"
            GridView1.DataBind()
        End Using
End Sub

Open in new window

I end up with the same problem, i went again and did some searching and i noticed that The ConnectionStringBuilder class allows you to parse the individual elements of a connection string and put them into the corresponding properties in the ConnectionStringBuilder. The ConnectionStringBuilder will then break it into the appropriate properties.

This approach i could not figure it out as there are no clear examples available except examples showing sensitive information like below:
Sub CreateConnectionString()
  Dim builder As New SqlConnectionStringBuilder
  builder.DataSource = "(local)"
  builder.InitialCatalog = "Northwind"
  builder.UserID = "user1"
  builder.Password = "P@ssw0rd"
End Sub

Open in new window

Can someone help me on how to pass the connection from the config file and use a class in order to call it in every page after extracting its appropriate properties.

Attached please find explanation files.
Thanks.
Vulnerabilitys.xlsx
Vulnerabilitys.docx
btan

Yet to have chance to read the doc but saw for sqlconnectionstringbuilder recommend avoiding use of username and password or minimally have them sanitise before use. not sure appscan is sensitive to that. if we use integrated authentication for the make of testing will the tool still complain...

http://msdn.microsoft.com/en-us/library/89211k9b(v=vs.80).aspx

There is an example of readding in the username answer password at the bottom of the article...wondering if tool will complain if use without hardcoding

http://msdn.microsoft.com/en-us/library/ms254947(v=vs.80).aspx
bduhaish

ASKER
Hello breadtan,

For your first question, i tried to use windows authentication and it complained due to an attacker may inject the connection by setting  Integrated Security to false or using extra semi-colons.

For the second question, i believe it is a sqlconnectionstringbuilder class exercise so from a security point it is solved but we need a developer to have a look on how to sanitized or extract the connection properties and then assign them into sqlconnection class.

Thanks.
All of life is about relationships, and EE has made a viirtual community a real community. It lifts everyone's boat
William Peck
btan

thanks for sharing. Looks like as long as they are parameter for SQL API  call (e.g. as in pt 1), Appscan will always be "not happy" with it since it flagged those option can be tampered.

Some sort of sanitisation (function to do the input validation) will still be needed so as to pass the scan as shared in pt 2.