หน้าเว็บ

Monday, July 20, 2015

เจาะระบบ WEB APP PHP/MYSQL และการป้องกัน

ชี้แจง

บทความนี้มีจุดประสงค์เพื่อนำเสนอให้เห็นช่องโหว่เรื่องความปลอดภัยของระบบ Web Application ที่ใช้ PHP/MySQL โดยจำเป็นต้องสาธิตขั้นตอนการเจาะระบบ เพื่อให้เห็นถึงจุดอ่อนและจะได้ทราบแนวทางป้องกัน ไม่ได้มีจุดประสงค์ชี้นำในการกระทำผิด ผู้ที่ใช้ความรู้ในทางที่ผิดต้องรับผิดชอบต่อการกระทำของตนเอง
… เข้าเรื่อง
โดยทั่วไปแล้ว ระบบ Web Application ที่เขียนขึ้นมาไม่ดี มักจะมีช่องโหว่ให้ผู้ไม่หวังดีเข้ามาโจมตีระบบ ไม่ว่าจะเป็นการทำ SQL Injection, XSS, Buffer Overflow หรือเทคนิคอื่นๆ ซึ่งถ้าสังเกตจากข่าวการโจมตีเว็บไซต์ส่วนใหญ่ก็มักจะโดนในรูปแบบนี้ มาดูกันดีกว่าว่าปัญหาแต่ละแบบคืออะไร โจมตีอย่างไร และป้องกันอย่างไร

1. SQL Injection

คือการแทรกคำสั่ง SQL เข้าไปในส่วนของการสั่ง Query ของโปรแกรม เพื่อให้โปรแกรมทำงานผิดพลาดหรือทำงานนอกเหนือไปจากสิ่งที่ผู้เขียนโปรแกรมกำหนด
สมมุติหน้าจอ Login ของเว็บไซต์หนึ่งมีช่องให้ผู้ใช้กรอก Username และ Password ดังรูป
เมื่อผู้ใช้คลิกปุ่ม Login ก็จะส่งข้อมูลจาก Form ไปที่หน้าสำหรับตรวจสอบค่าที่รับเข้ามา โดยมีส่วนของโค้ดในการตรวจสอบคร่าวๆ ดังนี้
$username = $_GET[‘username’];
$password = $_GET[‘password’];
$query = “SELECT * FROM users WHERE username=’$username’ AND password=’$password';”;
$result = mysql_query($query) or die(mysql_error());
if ($result && mysql_num_rows($result) == 1) {
// Login Successful
echo “Welcome ” . $username;
} else {
//Login failed
echo ‘Uername and/or password incorrect.';
}
การทำงานของโค้ดข้างบนนี้ก็คือ เอาค่า $username และ $password ที่ได้รับ เข้ามาเป็นเงื่อนไขของคำสั่ง Query เช่น ถ้า $username เป็น abc และ $password เป็น 1234 คำสั่ง Query ที่ได้จะเป็นดังนี้
SELECT * FROM users WHERE username=’abc’ AND password=’1234′;
ซึ่งโปรแกรมก็จะไปตรวจสอบในฐานข้อมูล ว่ามี username และ password นี้อยู่จริงหรือเปล่า ถ้ามีก็จะ SELECT ค่าใน row นั้นมา และผู้ใช้ก็จะสามารถ Login เข้าสู่ระบบได้เพราะใส่ username และ password ถูกต้อง แต่ถ้าไม่สามารถ SELECT ค่าได้ หมายความว่าผู้ใช้ใส่ username หรือ password ไม่ถูกต้อง ก็จะไม่อนุญาตให้เข้าสู่ระบบ

ตัวอย่างการโจมตี

ในการเจาะระบบ ทำได้โดยการใส่ค่า input ที่เป็นคำสั่ง SQL เพื่อให้เข้าไปเปลี่ยนการทำงานของคำสั่ง Query ตัวอย่างเช่น ใส่ค่า $username เป็น abc’ or ‘1’=’1 จะได้คำสั่ง Query ดังนี้
SELECT * FROM users WHERE username=’abc’ or ‘1’ = ‘1’ AND password=”;
ซึ่งผลที่ได้จากการใส่คำสั่งนี้คือ สามารถผ่านเข้าสู่ระบบได้โดยใช้ username ชื่อ abc โดยไม่จำเป็นต้องใส่หรือรู้ password เลย เนื่องจากว่าการใส่คำสั่ง or ‘1’=’1′ จะเป็นการทำให้เงื่อนไข username เป็นจริง และจะ Select เอาค่า row ในตารางออกมาได้
นอกจากการใส่คำสั่งเพื่อข้ามการตรวจสอบ username, password ได้แล้ว การทำ SQL Injection ยังสามารถแทรกคำสั่ง SQL อันตรายๆ ได้อีกด้วย เช่น DROP TABLE, DELETE, … ฯลฯ

การป้องกัน

ก่อนจะเอา input ที่ผู้ใช้ป้อน เข้ามามาเป็นส่วนหนึ่งของเงื่อนไขคำสั่ง Query ต้องมีการตรวจสอบค่าที่รับเข้ามาว่ามี Escape Character หรือเปล่า Escape Character ก็คืออักขระพิเศษในภาษา SQL ที่สงวนไว้สำหรับการเรียกฐานข้อมูล เช่น เครื่องหมาย ‘ (single quote) ใน MySQL โดยเมื่อ MySQL พบตัว Escape Character ก็จะถือว่าจบส่วนของคำสั่งนี้ และจะทำคำสั่งที่อยู่ถัดไป
ใน PHP มีฟังก์ชันที่ชื่อว่า mysql_real_escape_string() เพื่อเอาไว้กรอง Escape Character ของ MySQL เช่น เมื่อผู้ใช้ป้อนค่า $username เข้ามาเป็น abc’ or ‘1’=’1 แล้วเราเรียกใช้ฟังก์ชัน $username = mysql_real_escape_string($username) จะได้ค่า $username เป็น abc\’ or \’1\’=\’1 ซึ่งก็คือการเอาเครื่องหมาย \ ไปใส่ไว้ก่อนหน้าเครื่องหมาย ‘ นั่นเอง

ข้อมูลเพิ่มเติม

2. Cross Site Scripting (XSS)

คือการแทรกสคริปต์หรือแท็ก HTML ลงไปในหน้าเว็บ โดยปกติแล้วเทคนิคนี้มักจะพบได้ในระบบเว็บที่อนุญาตให้ผู้ใช้โพสต์ข้อความเข้ามา แล้วแสดงผลข้อความที่ผู้ใช้โพสต์ขึ้นมาบนหน้าเว็บ เช่น Guestbook, Webboard โดยตัวอย่างนี้จะสมมุติระบบ Guestbook มีช่อง Input ให้กรอก Name และ Message จากนั้นเมื่อคลิกปุ่ม Sign Guestbook จะไปทำคำสั่ง Query ดังนี้
$query = “INSERT INTO guestbook VALUES (‘$name’,’$message’);”;
จากนั้นส่วนหน้าเว็บที่แสดงผล Guestbook ก็จะเอาข้อความจากฐานข้อมูลมาแสดง

ตัวอย่างการโจมตี

ลองใส่โค้ด JavaScript ลงใน Guestbook ดังรูป
เมื่อคลิกปุ่ม Sign Guestbook ระบบก็จะเอาข้อความที่โพสต์ไว้มาใส่เป็นส่วนหนึ่งของหน้าเว็บ ทำให้ขึ้น Popup Message ขึ้นมา
การโจมตีแบบ XSS นอกจากจะสามารถฝังสคริปต์ในหน้าเว็บได้แล้ว ยังสามารถฝังองค์ประกอบ HTML อื่นๆ ได้หมด เช่น Iframe

การป้องกัน

เอาข้อความที่รับเข้ามา มาเข้าฟังก์ชัน htmlspecialchars() เพื่อแปลง HTML Tag ให้เป็นตัวอักษรธรรมดา เช่น ใช้คำสั่ง $message = htmlspecialchars($message); ซึ่งผลลัพธ์ที่ได้จะเป็นดังรูป
จากรูป จะพบว่า < ถูกเปลี่ยนเป็น &lt; และ > ถูกเปลี่ยนเป็น &gt;

ข้อมูลเพิ่มเติม

3. Cross Site Request Forgery (CSRF)

คือการใช้เทคนิค Social Engineer เพื่อหลอกให้เหยื่อคลิกลิงก์ที่มี Request บางอย่าง ซึ่ง Request ที่ว่านี้ จะทำงานได้ก็ต่อเมื่อผู้ใช้คนนั้น Login เข้าสู่ระบบเรียบร้อยแล้ว เช่น เปลี่ยน emain, เปลี่ยน password, ฯลฯ โดยปกติแล้ว เมื่อผู้ใช้ Login ผ่าน และเข้าสู่ระบบเรียบร้อยแล้ว โปรแกรมส่วนใหญ่จะใช้การสร้าง SESSION หรือเก็บ Cookie เพื่อยืนยันตัวผู้ใช้ การส่ง Request อะไรซักอย่าง ในขณะที่ผู้ใช้กำลัง Login อยู่ ก็เหมือนกับว่าผู้ใช้เป็นคนส่ง Request นั้นไปเอง

ตัวอย่างการโจมตี

สมมุติเว็บไซต์ธนาคารแห่งหนึ่ง ผู้ใช้จะสามารถโอนเงินได้ก็ต่อเมื่อ Login เข้าระบบแล้ว และการโอนเงินต้องส่ง Request ไปที่ Server ดังนี้
ในตัวอย่างนี้ คือการโอนเงินไปที่บัญชีของ BOB เป็นจำนวน 100
ถ้า Maria ต้องการหลอก Alice ให้โอนเงินมาให้ตัวเอง ก็ต้องหลอกให้ Alice ส่ง Request มาที่ Server ดังนี้
ซึ่งโดยปกติแล้ว ถ้าในตอนที่ส่ง Request นั้น Alice ไม่ได้เข้าสู่ระบบอยู่ การโอนเงินก็จะไม่สามารถทำได้ ดังนั้น Maria ก็อาจจะส่ง E-Mail หลอกๆ ไปหา Alice โดยหวังว่าในตอนที่คลิกลิงก์นี้ Alice น่าจะกำลัง Login เข้าระบบธนาคารอยู่
ซึ่งถ้าในตอนนั้น Alice กำลังเข้าระบบธนาคารอยู่ และคลิกที่ลิงก์นี้เข้าจริงๆ ก็เท่ากับว่า Alice โอนเงินไปให้ Maria ไปเลย 10000
ถ้า Alice คลิกที่ลิงก์นี้ อาจจะไปเจอกับหน้าเว็บของธนาคาร ที่ขึ้นข้อความบอกว่า “โอนเงินเรียบร้อยแล้ว” Alice จะรู้ว่าถูกหลอกให้โอนเงิน ทำให้แผนแตกได้ ดังนั้น Maria ก็อาจจะส่ง E-Mail ที่มีโค้ดข้างล่างนี้
<img src=”http://bank.com/transfer.do?acct=MARIA&amount=100000&#8243; alt=”” width=”1″ height=”1″ border=”0″ />
ซึ่งในโค้ดนี้ ก็คือการแทรกรูปภาพปลอมๆ เข้าไปในเมล ซึ่งเมื่อ Alice โหลดรูปภาพนี้ขึ้นมาดู ก็จะเป็นการส่ง Request ไปที่ Server บอกให้โอนเงิน โดยที่ Alice จะไม่เห็นข้อความบอกว่าโอนเงินเรียบร้อยแล้ว

การป้องกัน

ถ้าจะป้องกัน CSRF การเช็คแค่ HTTP Referer header นั้นป้องกันไม่ได้ เพราะ header สามารถถูกปลอมแปลงได้ เช่น ใช้ cURL หรือแม้กระทั่งการกำหนดให้ Request ที่เข้ามาเป็น POST อย่างเดียวก็ไม่สามารถป้องกันได้ เพราะถูกปลอมแปลงได้เช่นกัน ในการป้องกันที่ดีควรจะใช้การทำ Challenge/Response ในส่วน Request ที่สำคัญๆ

ข้อมูลเพิ่มเติม

4. Brute Force

การเจาะระบบโดยวิธี Brute Force เป็นการทดลอง Login โดยเดา Username หรือ Password แล้วส่งคำขอ Login ไปเรื่อยๆ จนกว่าจะสามารถเข้าสู่ระบบได้ ซึ่งการโจมตีสามารถทำได้ 2 แบบ คือ ใช้ฐานข้อมูล Password จาก Password Dictionary และทดลองสุ่ม Password ทุกตัวที่เป็นไปได้ (Brute Force) หรือจะใช้ทำวิธี Dictionary attack กับ Brute force attack คู่กันไปเลยก็ได้

ตัวอย่างการโจมตี

ใช้โปรแกรมสำหรับเจาะระบบ Login เช่น Hydra

การป้องกัน

ป้องกันการเดารหัสผ่าน เช่น กำหนดว่าถ้ามีการ Login ผิดเกินจำนวนครั้งที่กำหนด Account นั้นจะถูกระงั้บการใช้บริการ หรือถ้าทำไม่ได้ ก็ใช้วิธี Delay Login เช่น ถ้าใส่รหัสผิด ต้องรออีก 10 วินาทีถึงจะสามารถ Login ใหม่ได้ ซึ่งวิธีที่ 2 นี้สามารถลดความสามารถในการเดา Password ของโปรแกรมได้มาก เช่น ถ้าไม่ป้องกันเลย ใน 1 นาทีสามารถเดาได้ 1,000 รหัสผ่าน แต่ถ้าทำ Delay Login ไว้ 10 วินาที เวลา 1 นาทีก็สามารถเดาได้แค่ 6 รหัสผ่าน

ข้อมูลเพิ่มเติม

5. File Upload

ในระบบที่อนุญาตให้ผู้ใช้ Upload File จำเป็นต้องมีการตรวจสอบไฟล์ที่รับเข้ามา ก่อนที่จะเอาไฟล์นั้นไปใช้ต่อ การตรวจสอบแค่ extension ของไฟล์อาจจะไม่เพียงพอ เพราะ hacker สามารถแทรกโค้ดมากับไฟล์หรือส่งไฟล์อันตรายๆเข้ามาในระบบได้

ตัวอย่างการโจมตี

ในระบบ Unix ผู้ใช้สามารถตั้งชื่อไฟล์แบบนี้ได้ <script>alert(‘xxx’)</script>.jpg ซึ่งถ้ามีเว็บไซต์ที่อนุญาตให้ Upload File แล้วแสดงรายชื่อไฟล์ที่ upload ออกมาทางหน้าเว็บ ก็สามารถถูกโจมตีด้วยวิธี XSS ได้

การป้องกัน

กำหนดไว้เลยว่าไฟล์ที่ผู้ใช้ Upload มานั้น ตรงกับที่อนุญาตให้ Upload หรือเปล่า ซึ่งอาจต้องมีการตรวจสอบหลายๆ ชั้น ไม่ว่าจะเป็น ตรวจสอบขนาดไฟล์,ชื่อไฟล์,ตรวจสอบ Content,กำหนดสิทธิ์ของไดเรคทอรี่ที่เก็บไฟล์ ว่าให้สามารถ Read และ Write ได้อย่างเดียว ไม่สามารถ Execute ได้ รวมถึงการสแกนไวรัสไฟล์ที่อัพโหลดเข้ามาด้วย ถ้าทำได้

ข้อมูลเพิ่มเติม

ลองของจริง

สำหรับผู้ที่อยากลองเจาะระบบ Web Application ที่มีช่องโหว่ สามารถดาวนโหลดโปรแกรมที่ชื่อ Damn Vulnerable Web App มาลองเล่นได้ ซึ่งโปรแกรมนี้จะจำลองระบบที่มีช่องโหว่มาให้ ไม่ว่าจะเป็น SQL Injection, XSS สามารถดาวน์โหลดได้จาก http://www.dvwa.co.uk/ซึ่งนอกจากจะฝึกเจาะระบบได้แล้ว โปรแกรมนี้ยังมีตัวอย่าง Source Code ให้ศึกษาด้วย
ปล. ขอเตือนอีกรอบว่าบทความนี้มีจุดประสงค์เพื่อการศึกษาเท่านั้น ใครไปลองเจาะระบบของจริงก็ต้องรับผิดชอบเอาเองนะครับ

ที่มา : https://bigta.wordpress.com/2011/06/04/เจาะระบบ-web-app-phpmysql-และการป้องกั/
Posted by at No comments:
Labels: ,

PASSWORD HASHING & INPUT FILTERING

บทความนี้เป็นภาคต่อของบทความที่แล้วครับ คราวนี้จะมาว่ากันด้วยเรื่องของ Password hashing และ Input Filtering ซึ่งก็เป็นอีกเรื่องนึงที่สำคัญในการรักษาความปลอดภัยของระบบ Web Application

Password hashing

จากข่าวการแฮ็กเว็บไซต์ต่างๆ ในช่วงที่ผ่านมา หลายคนคงได้ยินว่า บางเว็บไซต์เก็บข้อมูลรหัสผ่านไว้แบบ Plain text ก็คือไม่ได้เข้ารหัส ซึ่งทำให้ใครก็ตามที่เจาะเข้าระบบได้ก็สามารถเห็น Username, Password และข้อมูลสำคัญๆ ทุกอย่างได้หมดเลย ดังนั้นเพื่อเป็นการป้องกัน มาดูกันดีกว่าว่าเราจะเก็บข้อมูล Password ในฐานข้อมูลยังไงให้ปลอดภัย
ก่อนอื่นมาว่าด้วยเรื่องของการ Hash กันก่อน
การ Hash คือการแปลงแปลงชิ้นส่วนของข้อมูล (ไม่ว่าข้อมูลจะมีขนาดเล็กหรือขนาดใหญ่) ให้เป็นข้อมูลชิ้นเล็กๆ ที่มีความสัมพันธ์กับข้อมูลเดิม โดยผลที่ได้จะอยู่ในรูปของ String หรือ Integer
ซึ่งการ Hash จะเป็นการทำงานแบบ One-way คือ ไม่สามารถเอาผลลัพธ์ที่ได้ไปหาย้อนกลับว่าข้อมูลต้นฉบับก่อน Hash คืออะไร
ตัวอย่างฟังก์ชัน hash ที่นิยมใช้กัน คือฟังก์ชัน md5()
$data = “Hello World”;
$hash = md5($data);
echo $hash; // b10a8db164e0754105b7a99be72e3fe5
ผลลัพธ์ของ md5() จะได้ข้อมูล 128 bit หรือ 16 byte แต่เนื่องจากข้อมูลที่ได้เป็นเลขฐาน 16 (1 ตัวอักษรใช้ 4 bit) ดังนั้นค่าที่ได้จะเป็น string ความยาว 32 ตัวอักษร
ในระบบ Web Application เมื่อผู้ใช้ทำการลงทะเบียน ก็จะเอารหัสผ่านที่ผู้ใช้ตั้ง มาเข้าฟังก์ชัน hash แล้วค่อยเก็บลงฐานข้อมูล ดังนั้นรหัสผ่านที่อยู่ในฐานข้อมูลก็จะไม่ใช่รหัสผ่านจริง และเนื่องจากฟังก์ชัน hash เป็น one-way ดังนั้นจึงไม่มีทางรู้ได้เลยว่าผู้ใช้ตั้งรหัสผ่านว่ายังไง แม้แต่ admin ก็ไม่มีทางรู้ (ซึ่งจริงๆ แล้ว admin ก็ไม่มีสิทธิ์รู้รหัสผ่านของผู้ใช้) และเมื่อผู้ใช้ Login เข้าสู่ระบบ ก็จะเอารหัสผ่านที่ผู้ใช้ป้อน มาเข้าฟังก์ชัน hash เดียวกัน แล้วเอาค่าที่ได้มาตรวจดูว่าตรงกับค่าที่อยู่ในฐานข้อมูลมั้ย ถ้าตรงกันก็แปลว่าผู้ใช้ใส่รหัสผ่านถูกต้อง
ถ้าดูจากแนวคิดข้างบน ระบบนี้ก็น่าจะปลอดภัย แต่จริงๆ แล้ว มันก็มีปัญหาเหมือนกัน

ปัญหาที่ 1 : Hash Collision

เนื่องจากขนาดของ Output เป็นค่าคงที่ ดังนั้น จึงอาจเป็นไปได้ที่ Input ต่างกัน แต่ได้ Output มาเหมือนกัน ปัญหานี้จะเกิดขึ้นถ้าฟังก์ชัน hash ที่ใช้ ให้ output ออกมาเป็นค่าที่มีความยาวน้อยๆ เช่น ฟังก์ชัน crc32() จะให้ค่าออกมาเป็น integer 32 bit ซึ่งความยาวของ output จะจำกัดอยู่ที่ 9 ตัวอักษร ดังนั้น ถ้ามี hacker เจาะเข้าฐานข้อมูลได้ แล้วได้ hash ของ password ไป ก็สามารถเขียนโปรแกรมเพื่อสุ่มสร้าง password ที่ให้ output ออกมาตรงกับค่า hash ที่ได้ ซึ่ง password ที่สร้างขึ้นมา อาจไม่ใช่ password จริงที่ผู้ใช้ตั้งก็ได้

วิธีป้องกัน

ใช้ฟังก์ชัน hash ที่ให้ค่าความยาวของ output ไม่น้อยจนเกินไป เช่น ฟังก์ชัน sha1() จะให้ output ที่มีขนาด 160 bit (40 ตัวอักษร)

ปัญหาที่ 2 : Rainbow Tables

ตารางสีรุ้ง!!? … ไม่รู้จะแปลเป็นไทยว่าไงดี งั้นไม่แปลละกัน …
Rainbow Tables คือตารางขนาดใหญ่ที่สร้างขึ้นจากการ hash คำพื้นๆ ที่นิยมนำมาตั้งเป็นรหัสผ่าน ซึ่งตารางนี้อาจจะมีข้อมูลเป็นหลักล้านหรือหลักร้อยล้านแถวเลยก็ได้ สมมุติว่า hacker เจาะฐานข้อมูลได้ และได้ username กับ hash ของ password ไป ก็จะเอา hash ที่ได้มาเทียบกับค่า hash ใน rainbow table ถ้าเกิดในระบบมีผู้ใช้ที่ตั้งรหัสผ่านโดยใช้คำพื้นๆ hash นั้นก็จะไปตรงกับ hash ที่อยู่ใน rainbow table จากนั้นก็ … เสร็จโจร!

วิธีป้องกัน

… โรยเกลือ … แปลไม่เป็นอีกแล้วสิ … อธิบายง่ายๆ ก็คือ เราจะสร้าง salt ขึ้นมา ซึ่ง salt ที่ว่า ก็อาจจะเป็นตัวเลขหรือตัวอักษรอะไรก็ได้ใส่เข้าไปมั่วๆ เพื่อที่จะนำมา concatenate กับ password แล้วค่อยเอาไป hash ตัวอย่างโค้ด
$password = “easypassword”;
echo sha1($password); // 6c94d3b42518febd4ad747801d50a8972022f956
$salt = “f#@V)Hu^%Hgfds”;
echo sha1($salt . $password); // cd56a16759623378628c0d9336af69b74d9d71a5
เท่านี้ก็ป้องกันได้แล้ว … รึเปล่า?

ปัญหาที่ 3 : Rainbow Tables (again)

… อีกแล้ว!!?
เนื่องจากว่า Rainbow Tables เนี่ย มันสามารถสร้างขึ้นมาใหม่ได้ ซึ่งถ้า hacker สามารถเข้ามาในระบบได้ แล้วรู้ว่า salt ที่ใช้คืออะไร (เช่น อ่านดูจากไฟล์ php) ก็สามารถสร้าง Rainbow Table ที่เกิดจากการเอา salt มาใส่กับรหัสผ่าน แล้วก็แกะรหัสผ่านได้อยู่ดี

วิธีป้องกัน

ใช้ “Unique Salt” คือ salt ของใครของมัน … ง่ายสุดก็เอา user_id นี่แหละมาทำเป็น salt ซะเลย
$hash = sha1($user_id . $password);
การ hash แบบนี้ทำได้ในกรณีที่ว่า user_id ไม่สามารถเปลี่ยนได้ ซึ่งก็ทำให้ hash แต่ละตัว มีค่า salt ของใครของมัน

ปัญหาที่ 4 : Hash Speed

ปัจจุบันนี้คอมพิวเตอร์ทำงานเร็วมาก ฟังก์ชัน hash ถูกออกแบบมาเพื่อให้สามารถคำนวนได้อย่างรวดเร็ว ดังนั้นจึงเป็นไปได้ที่ใน 1 วินาทีสามารถคำนวณ hash ได้เป็นพันล้านตัว โดยทั่วไปเราอาจคิดว่าการกำหนดให้รหัสผ่านมีความยาวอย่างน้อย 8 ตัวอักษร ก็น่าจะเพียงพอสำหรับการป้องกันการโจมตีแบบ Brute Force ได้ แต่จริงๆ แล้วไม่ใช่ ยกตัวอย่างเช่น
  • ถ้ารหัสผ่านประกอบด้วยตัวอักษรตัวพิมพ์เล็ก, ตัวพิมพ์ใหญ่ และตัวเลข ก็จะมีจำนวนอักขระที่สามารถใช้งานได้คือ 62 ตัว (26+26+10)
  • String ที่มีความยาว 8 ตัวอักษร ก็มีความเป็นไปได้คือ 62^8 ก็ประมาณ 218 ล้านๆ
  • ถ้าสามารถคำนวณ hash ได้ 1 พันล้านตัวใน 1 วินาที (สมมุติว่าใช้คอมหลายๆ เครื่องช่วยกันคำนวณ) ก็จะใช้เวลาแค่ 60 ชั่วโมงในการแกะ
ไม่ต้องพูดถึงรหัสผ่านที่มีความยาวแค่ 6 ตัวอักษรที่นิยมใช้กัน ซึ่งในความยาวแค่นี้ สามารถแกะได้ด้วยเวลาแค่ 1 นาที ดังนั้น การกำหนดความยาวขั้นต่ำของรหัสผ่านไว้ที่ 9 ถึง 10 ตัวอักษร ก็เป็นเรื่องที่สมเหตุสมผล

วิธีป้องกัน

ใช้ฟังก์ชัน hash ที่คำนวณนานๆ เช่น สามารถคำนวณ hash ได้แค่ 1 ล้านตัวต่อวินาที แทนที่จะเป็น 100 ล้านตัว ก็จะเพิ่มเวลาที่ hacker ใช้ในการแกะรหัสผ่านเป็น 1000 เท่า จากเดิม 60 ชั่วโมง ก็จะกลายเป็น 7 ปี
ใน PHP จะมีฟังก์ชัน cryp() ซึ่งใช้อัลกอรึทึม BLOWFISH ในการเข้ารหัส สามารถศึกษาวิธีการใช้งานได้ที่http://www.w3schools.com/php/func_string_crypt.asp
จะเห็นได้ว่า ในเรื่องของการรักษาความปลอดภัยนั้น ความร่วมมือของผู้ใช้ก็มีส่วนด้วย ดังนั้น ถ้าเป็นไปได้ ก็ควรกำหนดให้ผู้ใช้ตั้งรหัสผ่านที่มีความยาว 8 ตัวอักษรขึ้นไป และในรหัสผ่านนั้นต้องประกอบด้วยตัวอักษรตัวพิมพ์เล็ก, ตัวพิมพ์ใหญ่, ตัวเลข หรือมีอักขระพิเศษเข้าไปด้วยก็จะยิ่งดี บางระบบสามารถตั้งรหัสผ่านเป็นภาษาไทยได้ด้วย ซึ่งก็ยิ่งเพิ่มความปลอดภัยมากขึ้นไปอีก
ในกรณีที่ผู้ใช้ลืมรหัสผ่าน มีกรณีเดียวเท่านั้นคือ ต้อง Reset password และกำหนดรหัสผ่านใหม่ ซึ่งการ Reset รหัสผ่าน ก็จะใช้วิธีสร้าง One-time password ขึ้นมา เป็นรหัสผ่านที่ใช้เข้าระบบได้แค่ครั้งเดียว คือเข้ามาเพื่อกำหนดรหัสผ่านใหม่เท่านั้น
… สุดท้าย อย่างที่บอก ว่ารหัสผ่านที่เก็บในฐานข้อมูลนั้นต้องเป็นความลับ และต้องไม่มีทางหาย้อนกลับได้ว่ารหัสผ่านจริงๆ คือคำว่าอะไร ดังนั้น ถ้าเข้าเว็บไซต์ไหน ที่เมื่อเวลากด “Forget Password” แล้วมันสามารถบอกรหัสผ่านเดิมของเราได้ ก็มั่นใจได้เลยว่าถ้าเว็บไซต์นี้โดนเจาะ … ซวยแน่

Input Filtering

จากบทความก่อน ผมก็ลืมเรื่องที่สำคัญอีกเรื่องนึง คือการตรวจสอบ Input ที่รับเข้ามาจากผู้ใช้ ซึ่งเรื่องนี้ก็เป็นเรื่องใหญ่อีกเช่นกัน เนื่องจาก Input ทุกอย่างที่รับเข้ามาจากผู้ใช้ สามารถถูกสร้างขึ้นได้เองหรือปลอมแปลงมาโดยไม่ได้ผ่าน Interface ของเว็บเราก็ได้ ซึ่งถ้าไม่มีการตรวจสอบข้อมูลที่รับเข้ามา แล้วเอามาประมวลผลเลย อย่างนี้ไม่ดีแน่
สิ่งที่ต้องจำ คือ “ห้ามเชื่อข้อมูลทุกอย่างที่มาจากแหล่งข้อมูลภายนอก” ไม่ว่าจะเป็น
  • ข้อมูลจาก form
  • ข้อมูลจาก $_GET, $_POST, $_REQUEST
  • คุกกี้ $_COOKIES
  • ข้อมูลจาก Web service
  • ไฟล์
  • ตัวแปรบางอย่างจาก Server (เช่น $_SERVER[‘SERVER_NAME’])
  • ตัวแปร Environment
  • ค่าที่ได้จากการ Query ฐานข้อมูล
  • ฯลฯ
ข้อมูลทุกอย่างที่รับเข้ามา ต้องผ่านการกรอง (Filter) ก่อนนำมาใช้
Filter มีอยู่ด้วยกัน 2 ลักษณะ

1. Sanitizing filters

  • อนุญาตหรือไม่อนุญาตให้มีตัวอักษรที่กำหนดอยู่ใน string
  • Return ค่าเป็น String

ตัวอย่าง

FILTER_SANITIZE_SPECIAL_CHARS ตัด HTML escape character (เช่น ‘ ” < > &) ออกจาก string
FILTER_SANITIZE_URL ตัดอักขระอื่นที่ไม่ใช่ตัวอักษร,ตัวเลข และไม่ใช่ $-_.+!*'(),{}|\\^~[]`<>#%”;/?:@&=

2. Logical filters

  • Return ค่าเป็น TRUE หรือ FALSE

ตัวอย่าง

FILTER_VALIDATE_EMAIL ตรวจสอบว่าค่าที่รับเข้ามาอยู่ในรูปแบบของ e-mail หรือเปล่า
FILTER_VALIDATE_INT ตรวจสอบค่าที่รับเข้ามาว่าเป็นชนิด Int หรือเปล่า
ตัวอย่างการใช้งาน filter เพื่อตรวจสอบค่าที่รับเข้ามาว่าอยู่ในรูปแบบของ email หรือเปล่า
if (isset($_REQUEST[’email’])) {
if (!is_string($_REQUEST[’email’])) {
break;
}
$email = filter_input(INPUT_POST, ’email’, FILTER_VALIDATE_EMAIL);
}

ที่มา : https://bigta.wordpress.com/2011/06/12/php-password-hashing-input-filtering/
Posted by at No comments:
Labels: ,
Subscribe to: Comments (Atom)