Cara Mencegah Website Kita Terkena Sql Injection ASP.NET
SQL Injection adalah suatu metode yang sering digunakan para hacker untuk meretas situs tertentu. Dengan SQL Injection para hacker bisa mengakses database pada SQL, dimana database tersebut biasanya terdapat user dan password admin website tersebut. SQL Injection memang sangat berbahaya..
Bisa dilihat bahwa jika hacker sudah bisa masuk ke admin website, maka hacker bisa melakukan apa saja yang dia mau.
Bagaimana jika pada website kita terdapat bug Sql Injection ini ? bagaimana cara mencegahnya ?
Mari cegah sekarang sebelum terlambat diserang hacker..
Nah, penyebab yang paling sering terjadi adalah anda membuat pernyataan SQL tanpa menggunakan parameter dengan benar. Contoh seperti ini :
Jika Anda memiliki kode SQL seperti potongan di atas, maka seluruh database dan aplikasi Anda masuk ke golongan rentan. Bagaimana? Nah dalam skenario, hacker biasanya akan mencoba membobol situs menggunakan nomor jaminan sosial yang akan dilakukan seperti:
Ini akan dilakukan seperti apa yang developer harapkan, dan pencarian database untuk informasi penulis disaring oleh nomor jaminan sosial. Tetapi karena nilai parameter QL belum dikodekan, hacker bisa dengan mudah mengubah nilai querystring untuk menanamkan pernyataan SQL tambahan setelah nilai untuk mengeksekusi. Sebagai contoh:
Perhatikan bagaimana saya bisa menambahkan ‘;DROP DATABASE pubs — dengan nilai querystring SSN dan menggunakannya untuk mengakhiri pernyataan SQL saat ini (melalui karakter “;”), dan kemudian menambahkan sendiri pernyataan SQL yang berbahaya untuk string , dan kemudian keluar comment sisa pernyataan (melalui karakter”-” ). Karena kita hanya secara manual concatenating pernyataan SQL ke dalam kode kita, kita akan berakhir dengan melewati semua ini ke database, yang akan mengeksekusi query pertama terhadap tabel editor, dan kemudian menghapus tabel database pub kita. Dan semuanya akan hilang begitu saja
Cara Agar Terlindung Dari Serangan Tersebut
1) Jangan membangun Laporan SQL dinamis tanpa menggunakan mekanisme parameter encoding yang aman. Kebanyakan API data (termasuk ADO + ADO.NET) memiliki dukungan untuk memungkinkan Anda untuk menentukan dengan tepat jenis parameter yang disediakan (misalnya: string, integer, tanggal) dan dapat memastikan bahwa mereka dikodekan bagi Anda untuk menghindari hacker yang mencoba untuk memanfaatkannya. Selalu menggunakan fitur ini.
Misalnya, dengan SQL dinamis menggunakan ADO.NET Anda bisa menulis ulang kode di atas seperti di bawah ini untuk membuatnya aman:
Ini akan mencegah seseorang yang mencoba menyelinap ke dalam SQL, dan menghindari masalah data lainnya. Perhatikan bahwa desainer TableAdapter/DataSet built-ke VS 2005 menggunakan mekanisme ini secara otomatis, seperti halnya ASP.NET 2.0 kontrol sumber data.
Salah satu kesalahan persepsi umum adalah bahwa jika Anda menggunakan SPROCs atau ORM, Anda benar-benar aman dari Serangan SQL Injection. Hal ini tidak benar. Anda masih perlu untuk memastikan Anda berhati-hati ketika Anda melewati nilai ke SPROC, dan / atau ketika Anda pergi atau menyesuaikan permintaan dengan ORM yang Anda akan melakukannya dengan cara yang aman.
2) Selalu melakukan peninjauan keamanan aplikasi Anda sebelum menggunakannya. Titik ini adalah suatu yang super penting. Terlalu sering saya dengar dari tim yang melakukan peninjauan keamanan benar-benar rinci sebelum pergi tinggal, kemudian memiliki beberapa “benar-benar kecil” update mereka membuat ke situs minggu/bulan kemudian di mana mereka Sign In melakukan peninjauan keamanan. Selalu melakukan review keamanan.
3) Jangan pernah menyimpan data sensitif di dalam teks di dalam database. Pendapat pribadi saya adalah bahwa password harus selalu hash satu arah. ASP.NET 2.0 API melakukannya untuk anda secara otomatis secara default. Jika Anda memutuskan untuk membangun sendiri databese toko member Anda, saya akan merekomendasikan memeriksa sumber kode untuk pelaksanaan penyedia member kita sendiri bahwa kita dipublikasikan di sini. Juga pastikan untuk mengenkripsi kredit-kartu dan data pribadi lainnya dalam database Anda. Dengan cara ini bahkan jika database Anda disusupi, data pribadi setidaknya pelanggan Anda tidak dapat dieksploitasi.
4) Pastikan Anda menulis otomatisasi unit test yang secara khusus memverifikasi Anda ke lapisan akses data dan aplikasi terhadap serangan SQL Injection. Dan memberikan lapisan keamanan tambahan untuk menghindari sengaja memperkenalkan bug keamanan yang buruk ke dalam aplikasi Anda.
5) Mengunci database Anda. Jika aplikasi web Anda tidak memerlukan akses ke tabel tertentu, maka pastikan bahwa mereka semua tidak memilik izin untuk itu. Jika hanya read-only maka akan menghasilkan laporan dari tabel hutang account Anda maka pastikan Anda menonaktifkan insert / update / menghapus akses.
Bisa dilihat bahwa jika hacker sudah bisa masuk ke admin website, maka hacker bisa melakukan apa saja yang dia mau.
Bagaimana jika pada website kita terdapat bug Sql Injection ini ? bagaimana cara mencegahnya ?
Mari cegah sekarang sebelum terlambat diserang hacker..
Nah, penyebab yang paling sering terjadi adalah anda membuat pernyataan SQL tanpa menggunakan parameter dengan benar. Contoh seperti ini :
Dim SSN as String
Dim SqlQuery as String
SSN = Request.QueryString("SSN")
SqlQuery = "SELECT au_lname, au_fname FROM authors WHERE au_id = '" + SSN + "'"
Jika Anda memiliki kode SQL seperti potongan di atas, maka seluruh database dan aplikasi Anda masuk ke golongan rentan. Bagaimana? Nah dalam skenario, hacker biasanya akan mencoba membobol situs menggunakan nomor jaminan sosial yang akan dilakukan seperti:
' URL to the page containing the above code
http://mysite.com/listauthordetails.aspx?SSN=172-32-9999
' SQL Query executed against the database
SELECT au_lname, au_fname FROM authors WHERE au_id = '172-32-9999'
Ini akan dilakukan seperti apa yang developer harapkan, dan pencarian database untuk informasi penulis disaring oleh nomor jaminan sosial. Tetapi karena nilai parameter QL belum dikodekan, hacker bisa dengan mudah mengubah nilai querystring untuk menanamkan pernyataan SQL tambahan setelah nilai untuk mengeksekusi. Sebagai contoh:
' URL to the page containing the above code
http://mysite.com/listauthordetails.aspx?SSN=172-32-9999';DROP DATABASE pubs --
' SQL Query executed against the database
SELECT au_lname, au_fname FROM authors WHERE au_id = '';DROP DATABASE pubs --
Perhatikan bagaimana saya bisa menambahkan ‘;DROP DATABASE pubs — dengan nilai querystring SSN dan menggunakannya untuk mengakhiri pernyataan SQL saat ini (melalui karakter “;”), dan kemudian menambahkan sendiri pernyataan SQL yang berbahaya untuk string , dan kemudian keluar comment sisa pernyataan (melalui karakter”-” ). Karena kita hanya secara manual concatenating pernyataan SQL ke dalam kode kita, kita akan berakhir dengan melewati semua ini ke database, yang akan mengeksekusi query pertama terhadap tabel editor, dan kemudian menghapus tabel database pub kita. Dan semuanya akan hilang begitu saja
Cara Agar Terlindung Dari Serangan Tersebut
1) Jangan membangun Laporan SQL dinamis tanpa menggunakan mekanisme parameter encoding yang aman. Kebanyakan API data (termasuk ADO + ADO.NET) memiliki dukungan untuk memungkinkan Anda untuk menentukan dengan tepat jenis parameter yang disediakan (misalnya: string, integer, tanggal) dan dapat memastikan bahwa mereka dikodekan bagi Anda untuk menghindari hacker yang mencoba untuk memanfaatkannya. Selalu menggunakan fitur ini.
Misalnya, dengan SQL dinamis menggunakan ADO.NET Anda bisa menulis ulang kode di atas seperti di bawah ini untuk membuatnya aman:
Dim SSN as String = Request.QueryString("SSN")
Dim cmd As new SqlCommand("SELECT au_lname, au_fname FROM authors WHERE au_id = @au_id")
Dim param = new SqlParameter("au_id", SqlDbType.VarChar)
param.Value = SSN
cmd.Parameters.Add(param)
Ini akan mencegah seseorang yang mencoba menyelinap ke dalam SQL, dan menghindari masalah data lainnya. Perhatikan bahwa desainer TableAdapter/DataSet built-ke VS 2005 menggunakan mekanisme ini secara otomatis, seperti halnya ASP.NET 2.0 kontrol sumber data.
Salah satu kesalahan persepsi umum adalah bahwa jika Anda menggunakan SPROCs atau ORM, Anda benar-benar aman dari Serangan SQL Injection. Hal ini tidak benar. Anda masih perlu untuk memastikan Anda berhati-hati ketika Anda melewati nilai ke SPROC, dan / atau ketika Anda pergi atau menyesuaikan permintaan dengan ORM yang Anda akan melakukannya dengan cara yang aman.
2) Selalu melakukan peninjauan keamanan aplikasi Anda sebelum menggunakannya. Titik ini adalah suatu yang super penting. Terlalu sering saya dengar dari tim yang melakukan peninjauan keamanan benar-benar rinci sebelum pergi tinggal, kemudian memiliki beberapa “benar-benar kecil” update mereka membuat ke situs minggu/bulan kemudian di mana mereka Sign In melakukan peninjauan keamanan. Selalu melakukan review keamanan.
3) Jangan pernah menyimpan data sensitif di dalam teks di dalam database. Pendapat pribadi saya adalah bahwa password harus selalu hash satu arah. ASP.NET 2.0 API melakukannya untuk anda secara otomatis secara default. Jika Anda memutuskan untuk membangun sendiri databese toko member Anda, saya akan merekomendasikan memeriksa sumber kode untuk pelaksanaan penyedia member kita sendiri bahwa kita dipublikasikan di sini. Juga pastikan untuk mengenkripsi kredit-kartu dan data pribadi lainnya dalam database Anda. Dengan cara ini bahkan jika database Anda disusupi, data pribadi setidaknya pelanggan Anda tidak dapat dieksploitasi.
4) Pastikan Anda menulis otomatisasi unit test yang secara khusus memverifikasi Anda ke lapisan akses data dan aplikasi terhadap serangan SQL Injection. Dan memberikan lapisan keamanan tambahan untuk menghindari sengaja memperkenalkan bug keamanan yang buruk ke dalam aplikasi Anda.
5) Mengunci database Anda. Jika aplikasi web Anda tidak memerlukan akses ke tabel tertentu, maka pastikan bahwa mereka semua tidak memilik izin untuk itu. Jika hanya read-only maka akan menghasilkan laporan dari tabel hutang account Anda maka pastikan Anda menonaktifkan insert / update / menghapus akses.
Komentar
Posting Komentar