1195 次
4 に答える
2
スクリプトタグの置き換えの問題に具体的に答えると、これは手動のタスクである以外に何もわかりません。
あなたはこれを考慮したと確信していますが、フィールドでの単純な置換ステートメントは、このようなものを取り除く必要があります。
update MyTable
set field = replace(field, 'unwanted', '')
where field like '%unwanted%'
テーブルとフィールドが多数ある場合は、SQlデータディクショナリを使用して何らかの自動化を行うことができると確信しています。次のようなもの:
DECLARE @ColName varchar(255), @TableName varchar(255), @sSQL varchar(1000)
DECLARE colcur CURSOR for
SELECT name, object_name(id)
FROM syscolumns
WHERE name = 'Moniker'
OPEN ColCur
FETCH NEXT FROM ColCur
INTO @ColName, @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
Set @sSQL = 'update ' + @TableName + ' set ' + @ColName + ' = replace(' + @ColName + ', ''unwanted'', '''') where ' + @ColName + ' like ''%unwanted%'''
exec(@sSQL)
select @ColName, @TableName
FETCH NEXT FROM ColCur
INTO @ColName, @TableName
END
CLOSE ColCur
DEALLOCATE ColCur
于 2012-04-13T12:17:40.807 に答える
2
これらは、理想的なシナリオではいくつかのステップになると思います。
- サイトをオフラインに保ちます。404 ではなく、「Down to Technical Maintenance」メッセージを表示したい場合があります。
- ハッキングされたデータベースのバックアップを作成します。後で分析することができます
- SQL インジェクションに対して脆弱なコード部分を修正してください。より徹底するために、チームでこれを行うことをお勧めします。
- バックアップからデータベースを復元する
- (できれば) 固定のホームページをアップロードする
- 顧客データを漏洩した可能性があるため、弁護士に連絡してください。
- 弁護士と次の法的措置について話し合います。
おっしゃったように、ハッキングされたページには機密情報が保存されていませんでした。つまり、手順 6 と 7 をスキップできる可能性があります。
于 2012-04-13T13:31:33.337 に答える
1
データがどのように破損したか正確にはわからないため、バックアップがある場合は、これを使用するのに最適な時期です。バックアップがない場合は、将来バックアップを使用し、そのような攻撃から身を守るための教訓となるはずです。また、バックアップがない場合は、データをクリーンアップするアルゴリズムを作成する必要がありますが、ジャンクが残らないという保証はありません。
于 2012-04-13T12:19:34.793 に答える
0
次に、最近のバックアップからデータを復元します。
于 2012-04-13T12:12:13.300 に答える