Sembang Programming - Sembangan mengenai pengaturcaraan

Terdapat soalan yang menanyakan, apakah cara terbaik untuk menghalang SQL Injection yang diambil daripada Stack Overflow.

Cara terbaik untuk menghalangnya adalah dengan menggunakan prepared statement. Response tersebut juga menerangkan dengan lebih lanjut mengapa.

Memandangkan saya banyak menggunakan Perl/CGI sejak kebelakangan ni, post ni adalah berkaitan dengan perl/cgi.

Terdapat pengaturcara yang memandang ringan aspek sekuriti dalam perisian (kebanyakannya tak tahu, ignorance is bliss, no?) dan mengabaikannya sehinggalah suatu hari dimana perisian tersebut perlu menembusi pasaran yang lebih besar dan perlu melalui proses “penetration testing” (singkatan pen test) yang akan merungkaikan segala kelemahan yang telah diabaikan selama ini didalam pembangunan perisian tersebut.

Apabila terjadi begitu, maka bermulalah operasi menampal perisian daripada lubang-lubang sekuriti tersebut. Bagi kebanyakan input daripada pengguna dalam Perl/CGI, menggunakan “placeholder” adalah mencukupi untuk menyimpannya dengan selamat dalam pangkalan data (database) mengelakkan daripada SQL Injection. Rujuk article di perlmonks untuk penerangan lanjut, Preventing SQL injection attacks: Placeholders are enough for MySQL, Postgresql and SQLite.

Apa bendakah itu “placeholder”?
Placeholder adalah nilai yang digunakan untuk menggantikan sesuatu nilai yang lain.

Berikut adalah contoh penggunaan placeholder.

$sth = $dbh->prepare( "SELECT name WHERE city = ? AND state = ?" );
$sth->execute( $city, $state );

Dengan menggunakan placeholder, modul DBI akan secara automatik menguruskan isu-isu “quoting” (escape single/double quote, e.g. \”) didalam nilai yang dihantar kepada pangkalan data.

Kekurangan “placeholder”
Walaupun semua jenis input selamat dimasukkan kedalam database dengan menggunakan placeholder tanpa mengakibatkan SQL Injection, ia masih perlu diperiksa kesahihannya. Anda masih perlu untuk mengesahkan (validate) input yang dimasukkan samada ianya integer, numeric, alpha, alphanumeric, dsbnya.
Jika input tersebut adalah berbentuk HTML, tukarkan semua character ke dalam HTML Entities, untuk mengelakkan daripada kes-kes XSS (Cross-site Scripting). Jika tiada HTML dibenarkan, gunakan HTML::Scrubber untuk sental semua html daripada input tersebut.

Berikut adalah contoh untuk menukarkan character-character ke bentuk HTML Entity

use HTML::Entities;
sub html_to_db{
    my ($html) = @_;
	$html = encode_entities($html);
	$html =~ s/\r\n//gs;
	return $html;
}

Marilah kita sama sama belajar mempertahankan diri daripada anasir-anasir yang tak diingini apabila membangunkan perisian.

Selamat programming!

Dalam pos ni, saya akan pos contoh kod untuk membersihkan input menggunakan perl. Mungkin ada module dalam CPAN yang dapat melakukannya tetapi saya tidak jumpa, mungkinkah ianya HTML::Scrubber? Saya pun tak pasti (dah lama tak buat perl).

Kod dibawah agak ringkas.

use HTML::Entities ();
use CGI qw/:standard/;

$query = new CGI;

$username	= $query -> param('username');
$password	= $query -> param('password');

$sql = qq~
	SELECT somefields
	FROM user
	WHERE username = ?
	AND password = ?
~;

$ok_chars = 'a-zA-Z0-9 ,-';
$c_username = HTML::Entities::decode( $username);
$c_username =~ s/[^$ok_chars]//go;

$dbquery = $conn->prepare($sqlstatement);
$dbquery->execute("$c_username", "$password" ) or &error("SQL&Couldn't execute statement: $DBI::errstr");

Jika ada cara lain, silalah kongsi! Terima kasih.

Bagaimana anda menghasilkan kata laluan pengguna apabila akaunnya dihasilkan? Menggunakan MD5? SHA-1? Ok, bagus kerana encrypt kata laluan kerana kebanyakan orang menggunakan kata laluan yang sama untuk pelbagai perkhidmatan (services).

Apa akan jadi kalau tak encrypt kata laluan?

Tak jadi ape ape pun dari segi fungsi aplikasi, tetapi akibatnya adalah dari segi perundangan (link menerangkan Data Protection Act di UK, tak pasti di Malaysia ada ke tak). Kalau orang dapat masuk server melalui exploit OS ataupun perisian lain kemudian dump database, mereka terpaksa lalui lagi satu halangan, encrypted password. Kalau tak encrypt (istilah ‘tak encrypt’ selalu digunakan sebagai ‘plain-text’)? Larian tanpa halangan la jawabnya.

Ok, dah encrypt? Cukupkah?

Tak cukup! Kena tambah garam (salt) sikit, sebagai penambah perisa. Kenapa? Sebab teks yang telah encrypt tu boleh dipadankan dengan menggunakan pengkalan data seperti GData: An Online MD5 Hash Database. Bahayakan?

Bila tambah garam sikit, agak sukar untuk teks tersebut ditukar kembali (reverse lookup) kerana ia takkan jumpa walaupun anda menggunakan kata laluan generic seperti qwe123.

Jadi, macam mana nak tambah garam?

$salt = substr($password, 1, 3);
$e_password = md5($password . $salt);

Macam tu je. Mudah. Harap maklumat ni dapat membantu sedikit sebanyak.

Edit: Menggunakan $salt pada $e_password = md5($password . $salt)