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

What if textbox1.Text  =

''; select * from users

nothing will happen.

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())

Select all Open in new window

Thanks.

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

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

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.

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>

Select all Open in new window

After Encrypting.

<configuration>
   <configProtectedData>
      <providers>
   <!-- contents -->
      </providers>
</configProtectedData>

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

Select all 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

Select all 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

Select all 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

Select all 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

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

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.

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.