#SQL_Injection

[kiiboii]

🔒 Bahaya SQL Injection: Kenapa Website Kamu Butuh Perlindungan!

Hai teman-teman! Pernah nggak sih kepikiran kalau data di website bisa bocor cuma karena satu celah kecil? Nah, itu bisa banget terjadi kalau website kita rentan terhadap SQL Injection. Aku baru aja nyobain eksperimen simpel dan juga sebagai bagian dari tugas aku gimana bahayanya, dan aku mau sharing biar kalian juga paham dan tahu cara melindungi situs kalian. Yuk, simak!

Apa Itu SQL Injection?

Jadi begini, SQL Injection itu kayak hacker nyisipin kode jahat ke website lewat inputan yang seharusnya aman. Kalau kita nggak hati-hati, kode itu bisa bikin mereka mengakses semua data di database, bahkan mengubah atau menghapusnya! Bayangin, data pribadi, password, sampai data penting lain bisa diambil cuma karena website kita nggak aman.

Eksperimen Sederhana: Melihat Kerentanan Website

Aku buat website kecil pakai PHP dan MySQL buat coba-coba. Contohnya kayak gini:

Kalau akses URL-nya kayak gini:

maka akan tampil data pengguna ID = 1

Tapi kalau diubah jadi: http://localhost/uas/index.php?id=1' OR '1'='1

tiba-tiba semua data pengguna muncul! Ini bahaya banget, kan? Website itu rentan banget kalau nggak diproteksi.

Kenapa Bahaya?

Serangan kayak gini bisa bikin data bocor, diubah, atau dihapus sama pihak nggak bertanggung jawab. Kalau data penting kayak password, data pelanggan, atau info rahasia lain bocor, reputasi dan kepercayaan bisa rusak parah.

Solusi Ampuh: Pakai Prepared Statements

Gampang banget, tinggal pakai prepared statements. Contohnya kayak ini:

Nah, dengan cara ini, input dari pengguna dianggap sebagai data, bukan bagian dari query SQL. Jadi, serangan kayak tadi nggak bakal berhasil lagi!

Tips Tambahan buat Website Aman nihh

Validasi input: Pastikan data yang masuk sesuai format yang diharapkan.

Update software & plugin: Biarkan selalu terbaru buat nutup celah.

Batasi hak akses database: Jangan kasih hak penuh ke user database.

Backup rutin: Kalau terjadi sesuatu, data bisa dipulihkan.

Kesimpulan

Gak mau kan data kita gampang diambil orang? Pelajaran pentingnya, jangan remehkan soal keamanan. Dengan langkah simpel kayak pakai prepared statements, kita bisa jauh lebih aman dari serangan SQL Injection. Yuk, mulai perhatikan keamanan website dari sekarang! Karena data kita berharga banget, guys.

Kalau kalian suka dan mau belajar lebih jauh soal keamanan web, comment atau repost ya! Aku bakal bahas lagi soal tips dan trik lainnya. kalo ingin lebih liat lengkap caranya gimana bisa langsung ke Github-ku yaa. Cheers! ✨

Referensi

https://owasp.org/www-community/attacks/SQL_Injection

https://www.php.net/manual/en/mysqli.prepare.php

[nehaarticles]

The main difference between them is that IN selects a list of matching values, whereas EXISTS returns the Boolean value TRUE or FALSE.

[crackeverythingyouget]

Something Awesome: Cyber

I did not get much time to work on the Something Awesome project this week. However, I am pretty much done with building the website. 

I took a bit of CSS help from YouTube (cause I did not want it to look awful) and built a very simple blog. I might have to switch up my something awesome timeline. I probably should finish by week 7 so that I can allocate time for job application in week 8. The blog lets you add posts randomly into the homepage. I’ve tried adding some basic security like avoid script tags as query input and other features like this to avoid exploitation and make it harder for me so that I’d have to work hard to exploit. I’ve already started researching about the exploits. (https://medium.com/front-end-weekly/slow-loris-rethinking-dos-attacks-bd1ca5091bfe, https://en.wikipedia.org/wiki/Denial-of-service_attack, https://en.wikipedia.org/wiki/Cross-site_scripting, https://www.owasp.org/index.php/Cross-site_Scripting_(XSS), https://en.wikipedia.org/wiki/SQL_injection, https://www.owasp.org/index.php/SQL_Injection). I’ll do a couple of Natas exercises (just enough to get started) to get better first as well. Looking forward to executing some attacks on the page this week!

[ryankelley]

SQL Injection in Ruby

When one is building applications that will be hosted on closed network, perhaps at a small office, it may seem tempting to skimp on time allotted to ensuring application security. But this is certainly a mistake. "It's unlikely" or "it's not worth the time" or "this isn't Google" should never be the sentiment. The truth is, no matter how small the organization, security is always crucial when building a web application--or really anything for that matter. One often exploited aspect of web applications is SQL injections via client inputs. In Rails, if developers aren't careful with their user input and escaping query strings, they can make it very simple for attackers to steal, destroy and otherwise manipulate sensitive data.

SQL Injection attacks are particularly dangerous because they provide access to your application's database.

Good rules of thumb are:

1.) Use prepared statements and parameterize queries. In Rails, use hash or array syntax when constructing your where clauses. Hash key-value pairs will escape arguments while the array form will safely parameterize the query.

Prepared statements prevent attackers from changing the funtionality of the query, even when SQL commands are inserted. If an attacker enters a parameter as "x OR 1=1" while querying the email column in the user's table, the parameterized query would look for a an email which literally matched "x OR 1=1" instead of activating the OR clause.

2.) Escape all user supplied input and attempt to avoid direct user input when performing queries. In many cases, malicious users can easily insert UPDATE and DESTROY statements into queries with interpolated arguments.

Here are some examples of how SQL injection works:

params = {} ## Using string interpolation in where clauses is always dangerous ## BAD (Strings unescaped) params[:firstname] = "'cat' OR lastname='Kelley'" User.find(:first, conditions: "firstname = #{params[:firstname]}") #=> AR Relation matching conditions ## GOOD (Escaped/Parameterized via Hash or Array) User.find(:first, conditions: {firstname: params[:firstname]}) #=> nil ## OR User.find_by_firstname(params[:firstname]) #=> nil ## OR User.where(firstname: params[:firstname]).first #=> nil ## BAD Where Clause params[:email] = "'' OR is_admin=1" User.where("email = #{params[:email]}").first #=> AR Relation with admin user ## GOOD User.where(email: params[:email]).first #=> nil ## OR User.find_by_email(params[:email]) ## More to Avoid ## Bad and Weird params[:column_name] = "ip_address from customers where email like '%rkelley%'--" Customer.pluck("DISTINCT #{params[:column_name]}") ## Never Pass an Input Directly to :destroy_all, :delete_all, :update_all params[:account_active] = "'' OR 1=1--'" Customer.destroy_all("uid = ? AND account_active=#{params[:id]}", params[:uid]) params[:email] = "' OR 1=1;" Customer.where("email LIKE '%#{params[:email]}%'").update_all(inactive: true)

[caylakyazilimci]

mysql_real_escape_string / Güvenlik

Mysql gayet vefalı bir dost gibi depoladığımız her şeyi sır gibi saklar ta ki biz çağırana kadar.Bu vefalı dosta karşı bizde iyi davranmalıyız ki karman çorman veri yıgınları oluşturmayalım ve ilerde büyük sorunlar yaşamayalım veya bu yolladığımız veriler başkalarının eline geçmesin.

Ne saçmalıyor bu şeklinde düşünüyor olabilirsiniz ama ilk öğrenmemiz gerekenlerden biri mysql tablolarımızı gereksinimlerimiz doğrultusunda kullanım amacımıza yönelik oluşturup yolladığımız verilere de dikkat etmektir kendi kanaatimce.

Verilerin başkalarının eline geçmemesi noktasında mysql_real_escape_string e ihtiyacimiz var.Veri hırsızları ve kendine hacker diyen kişiler unutmayınki bilgilerinizin ve sitelerinizin peşinde çağımız bilgi çağı en büyük değer bilgi olmuş durumda.

Peki nasıl faydalanacağız bilgilerimizin başkalarının eline geçmemesi için mysql_real_escape_string fonksiyonundan ne işe yarar bu fonksiyon.

sql_injection : mysql veritabanınıza sitenizdeki kullanıcıdan ve dışardan aldığınız verileri yeterince süzmeden kayıt gerçekleştiriyorsanız muhtemelen başınıza gelecek şey.Sql injectiona veritabanınıza sitenizdeki formlar aracılığı ile get veya post metodları ile aldığınız bilgileri kayıt ederken süzmemeniz sebep olur.bu metod ile işini bilen bir hacker sizin sitenizi komple eline geçirebilir.

Nasıl Korunurum sql injection dan ?

Sitenizde dışardan herhangi şekilde veri alıyorsanız bu verileri önce tehlike arz edebilcek bilgilerden istenmeyen bilgilerden arındırmak için önceden hazırladığınız süzgeç fonksiyonundan geçirebilirsiniz ki birçok programcı bu metodu kullanır.Bu süzgeç sistemi içersinde mysql komutlarını da süzülecek elemanlar olarak ayarlamışsanız endişe edilecek bir durum kalmamıştır.Şayet süzgeç fonksiyonunuz yeterli değilse bu konuda mysql_real_escape_string yardımımıza koşuyor ve veriyi mysql komutlarından temizliyor.

mysql_real_escape_string Fonksiyonunun Kullanımı

Kullanacağınız satır öncesinde mysql bağlantısını yaptıysanız

$temizveri=mysql_real_escape_string($veri); // bir değişkene atadığınız veriyi temizleme

$temizveri=mysql_real_escape_string($_POST[veri]);  //post metodu ile alınan veri temizleme

$temizveri=mysql_real_escape_string($_GET[veri]); // get metodu ile alınan veri temizleme

mysql sorgusu sırasında da kullanılabilir.

mysql_query("SELECT * FROM kullanici_tablo WHERE kullanici ='".mysql_real_escape_string($kullanici)."' and sifre='".mysql_real_escape_string($sifre)."');