VietNetwork.Vn

1. Giới thiệu.

PHP là  một ngôn ngữ lập trình mã nguồn mở, đáp ứng cho sự phát triển ứng nền tảng Web và sử dụng song song với mã HTML. Ngôn ngữ lập trình PHP với cách thức viết rất gẫn gũi với ngôn ngữ lập trinh C và Perl, tuy nhiên PHP viết dễ dàng và không cầu kỳ như ngôn ngữ lập trình C hoặc Perl với cách đặt biến dễ chịu.

PHP có thể chạy trên nhiều hệ điều hành như Linux, Unix, Windows, MAC OSX, OpenBSD... nhưng phổ biến rộng rãi hiện nay vẫn là Linux. PHP được tích hợp với các dạng máy chủ như Apache và IIS. PHP hổ trợ được nhiều loại cơ sở dữ liệu như: MySQL, Oracle (OCI7 and OCI8) MySQL, ODBC... và những loại cơ sở dữ liệu khác. Hiện nay MySQL thì phổ biến nhất.

MySQL cũng giống PHP ở chỗ cùng là phần mềm mã nguồn mở. MySQL có tốc độ tải dữ liệu nhanh chóng và dễ sử dụng. PHP và MySQL có thể được coi như là một giải pháp tối ưu để phát triển cơ sỡ dữ liệu trên Internet hiện nay nhờ sự tiện dụng và hiệu quả của nó, thích hợp cho các cá nhân, tổ chức, doanh nghiệp thực hiện thương mại điện tử. PHP và MySQL có thể được tải về miễn phí tại 2 địa chỉsau đây:

• http://www.php.net (http://www.php.net)
• http://www.mysql.com (http://www.mysql.com)

2. Những lỗi thường gặp với PHP và MySQL.

Dạng truyền biến:

• Khi lập trình chúng ta thường thấy nhiều lỗi do cách thức truyền biến ra Internet Explore hoặc Netcape do thiết kế Form. Khi Submit một Form nào đó thì các biến trong Form có thể truy xuất ra và được sử dụng như là biến toàn cục (global) $_POST, $_GET, $_VAR... Ngoài cách đưa biến từ Form thìcòn có session và cookies.
• Mỗi đường truyền biến bao giờ cũng có cái lợi và các hại của nó. Ở đây mình xin đề cập đến vấn đề tác hại của nó.
• Khi một lập trình viên lập trình với PHP nếu không cẩn thận sử dụng biến có thể dẫn đến nhiều sự nguy hiểm khác nhau.
• Các thức truyền biến được xem là nguy hiểm nhất là dạng truyền biến trên Address Bar của các trình duyệt Web. Khi đó kẻ tấn công có thể lợi dụng những sơ hở này để khai thác các lỗ hổng nguy hiểm như SQL Injection.
• Ví dụ khi bạn sử dụng các biến trực tiếp trên Address Bar để dùng cho các mệnh đề Logic, thì thường dễ bị vượt qua.

if ($hello) echo "hello";

• Đoạn mã trên cho thấy nếu tồn tại biến hello rồi sẽ thực thi. Vậy vấn đề chỉ cần cho nó tồn tại. Vì thế ta nên kiểm tra biến với một giá trị nào đó, xác định thì lỗi có thể được thông qua nhưng nếu mã nguồn của bạn đã được kiểm tra thì điều này coi như vô nghĩa. Mình sẽ nói sau ở mục PHP Axploit Local.
• Submit Form với hình thức GET thì các biến trong Fform sẽ được truyền trực tiếp lên address bar và nếu sử dụng biến toàn cục đó liên quan đến Uncode thì... hiệu quả sẽ giảm đi. Chẳng hạn bạn tạo một Form như sau:

< input name="key" type=text >
< input type=submit value="Test" >
< /form >

• Xin được nói sơ qua về SQL Injection với cách truyền biến này. Ví dụ như sau:

$a = mysql_query("SELECT * FROM user $osd");

• Nếu biến $osd trên address bar lộ ra ORDER by id DESC thì ta có thể thay thế biến $osd với một giá trị khác là mã PHP chẳng hạn. Vậy chẳng khác nào chúng ta đã tạo điều kiện cho kẻ tấn công thực hiện những hành động chết người. Ví dụ như sau:

$osd="); mysql_query("INSERT INTO user .....");

• Khi bạn nhập text với dạng Unicode thì khi truyền trên address bar các ký tự sẽ không còn chính xác nữa. Vậy làm cách nào khắc phục. Có khá nhiều cách làm, các bạn có thể sử dụng cookies, session hay hidden biến đó đi.
• Về vấn đề đặt biến dạng hidden trong Form HTML. Lợi thì có lợi nhưng hại vẫn có. Ví dụ như sau: Nếu bạn đặt một biến hidden nào đó dùng để kiểm tra hoặc cho một mệnh đề Logic thực thi thì khả năng bảo mật sẽ không còn, chỉ cần view source trong trình duyệt Web là lộ nguyên hình. Và khi kẻ tấn công có thể tạo ra các biến đó thì việc kiểm tra mệnh đề Logic đó coi như vô nghĩa.
• Và khi cho phép nhận thông tin từ các Input để đưa vào CSDL rồi chuyển tải ra Website, nếu không lọc những thẻ HTML cho phép thực thi JavaScript thì cũng nguy hiểm không kém. Kẻ tấn công sẽ tận dụng để nhúng các Mailware, thự thi các đoạn mã ăn cắp thông tin như Cross Site Scripting.

Sử dụng biến từ Cookies:

• Cookies rất hiệu quả để chứa những thông tin, nhưng lạm dụng nó quá có thể dẫn đến nguy hiểm. Nếu một lập trình viên đặt cookies chứa các thông tin về một tài khoản nào đó thì chỉ cần xem cookies là xem như bị lộ thông tin rồi. Cách khắc phục là mã hóa nó hết. Ví dụ một cookies sau đây:

userid=11
passhash="helloall"

• Vấn đề ở đây là về việc chứa thông tin không cần thiết là mật khẩu của tài khoản. Dù mã hóa hay không mã hóa vẫn nguy hiểm. Nếu mã hóa dạng thông thường như dạng base64, crypt... thì vẫn có khả năng dịch ngược được và dạng MD5 thì vẫn có thể tấn công kiểu Brute Force. Vậy cookies những gì cần thiết chứ không nên chứa những thông tin mang tính nhạy cảm và cần bảo mật. Đó là những lỗi cơ bản, vỉ thời gian có hạn nên mình chỉ nêu một vài lỗi như vậy.

3. Safe Mode PHP và MySQL Local Exploit.

Đây là một lỗi bảo mật nguy hiểm nhất, nói nôm na là kỹ thuật khai thác thông tin từ các Website sử dụng Web Shared Hosting trên cùng một máy chủ. Ví dụ khi bạn có một Website ở máy chủ 1 và kẻ tấn công cũng có chung một Website ở cùng máy chủ này với các bạn, và chung luôn ổ đĩa với bạn thì hết sức nguy hiểm.
Kẻ tấn công có thể làm mọi việc tùy theo mức độ bảo mật của máy chủ đó, cụ thể như xem mã nguồn, tìm lỗi bảo mật của lập trình, xem thông tin tài khoảng Web Shared Hosting của bạn như username, password, email, chiếm luôn cả máy chủ, by pass... Minh xin được nói sơ về lỗi này.

• Chỉ cần một vài Backdoor trên máy chủ thì nguy hiểm không lường. Khi cơ sỡ dữ liệu của bạn dùng MySQL để lộ mật hẩu, user của database thì việc hủy diệt cơ sở dữ liệu đó hoàn toàn có thể thực thi như DROP, QUER , INSERT... Và đặc biệt nguy hiểm đối với các máy dùng cPanel để quản lý Web Shared Hosting cho mỗi tài khoản. Một số cấu hình máy chủ cPanel cho phép tạo ra tên cơ sở dữ liệu có trùng với tài khoải của cPanel, FTP, Webmail, POP3... và chỉ một vài thủ thật nhỏ của kẻ tấn công thì Website của bạn có thể thuộc quyền kiểm soát của chúng với đầy đủ quyền hạn.
• Nếu PHP chạy trên Linux thì việc soi máy chủ để tìm thông tin chỉ là việc đơn giản nhưng cũng tùy theo mức độ bảo mật của máy chủ đó. Tình hình hiện nay với một số công ty Web Shared Hosting Việt Nam sử dụng PHP và MySQL trên Linux cũng rất nhiều và việc bảo mật còn khá sơ sài. Vì vậy phát triển thương mại điện tử muốn an toàn trước hết phải bảo mật cơ sỡ dữ liệu của bạn một cách an toàn nhất có thể. Ngoài cách trên ra, còn có lỗi bảo mật của Web Server Apache, mức độ tận dụng cũng rất cao với lỗi này, đó là Apache Chunked.
• Nguyên nhân xảy ra lỗi này:
• Safe mode: được bật.
• Các thư mục chưa được set quyền.
• Chưa cấu hình kỹ cho PHP php.ini.
• PHP cho phép cấu hình từ bất kỳ người dùng php.ini.
• MySQL cho phép truy xuất vào cơ sỡ dữ liệu với Web Shared Hosting như localhost.
• Như ta thường biết, để đưa bất cứ dữ liệu từ người sử dụng vào CSDL ta đều thông qua dạng truyền biến Form HTML, gồm nhiều dạng và nhiều cách khác nhau. Vì thế lỗi cũng rất nhiều nếu ta không kịp ngăn chặn, có thể dẫn đến những hậu quả khó lường. Dù truyền biến dạng POST, GET thì lỗi vẫn có. Và lỗi nghiêm trọng là dùng các biến ẩn để so sánh hoặc thực thi một mệnh đề Logic nào đó. Ví dụ bạn làm một biến ẩn như password, email... thì kẻ tấn công có thể view source của bạn, thay đổi các trường và thay đổi luôn action. Vì thế nếu lỗi thì kẻ tấn công có thể tấn công trực tiếp từ những lỗi này với vài thủ thuật nêu trên.

Cách khắc phục:

• Không đặt những biến ẩn với mục đích so sánh hay thực thi mệnh đề Logic. Nếu các bạn lập trình đưa trực tiếp các biến vào thẳng cơ sở dữ liệu mà không thông qua một bước kiểm tra nào đó thì cực kỳ nguy hiểm.
• Các nguy hiểm có thể xảy ra như Cross Site Scripting, SQL Injection, Buffer Overflow trong MySQL. Vì vậy bước kiểm tra các biến vào hết sức quan trọng.
• Cross Site Scripting: Để khắc phục lỗi này thì các bạn nên xử lý biến vào theo kiểu chặn các tag HTML, các hàm PHP hỗ trợ làm việc đó như str_replace, strip_tags, htmlspecialchars, htmlentities... các bạn có thể tham khảo thêm về các hàm xử lý chuỗi để xử lý các tag như < > chuyển sang mã HTML hay thêm ký tự nào vào, thay thế các text như onmouseover, onload...
• SQL injection: các biến đưa vào thường rất nguy hiểm nếu dính dấu ` hay "" hoặc # vì vậy cách khắc phục cũng như trên hoặc thêm hàm addslashes.
• Buffer Overflow trong MySQL: cái này thường rất nghiêm trọng, khi bạn đưa biến vào cơ sở dữ liệu mà không chống Flood thì kẻ tấn công có thể Refresh trình duyệt Web hoặc dùng những tập tin tấn công từ máy chủ, Web Shared Hosting hoặc localhost, làm tràn máy chủ khiến tắt nghẽn và nhà cung cấp Web Shared Hosting có thể hủy đồng với dịch vụ của bạn. So sánh biến nhập vào trùng hay thời gian... nói chung là có nhiều cách để làm việc này, hiệu quả và nhanh chóng thì dùng hàm header sau khi submit. Nếu các bạn lập trình dùng hàm mysql_fetch_array thì cũng dễ bị tràn máy chủ, lý do là gom dữ liệu vào mảng nếu nhiều record thì thế nào... vì vậy bạn có thể chuyển qua dùng mysql_result, nó lấy dữ liệu theo filed và column.
• Chú ý về dạng upload file: cái này cũng quan trọng không kém, vì thế bạn phải kiểm tra dạng tập tin là gì khi được tải lên, vì nếu không sẽ có thể làm Web Shared Hosting của bạn dính Backdoor hoặc Malwares.

4. Flood Form là gì?.

• Flood Form là dạng gửi dữ liệu hàng loạt khiến cho máy chủ cơ sở dữ liệu xử lý quá tải, ví dụ bạn thiết kế một Form đơn giản chỉ INSERT data vào MySQL. Nếu dDữ liệu chỉ là một request thì không sao, còn trong một giây mà có hàng trăm request thì lập tức Database Server sẽ bị tràn ngập. Hiện tại có khá nhiều Website thiết kế Form không có mã xác nhận nhằm chóng tấn công thì vấn đề gì sẽ xảy ra?.
• Nếu những Form như góp ý, đăng ký thành viên thì lâu lâu có cả ngàn record do flood là chuyện thường. Nếu Form xử lý có gửi mail thì đương nhiên bị lợi dụng để làm Bomb Mail, làm đầy cơ sở dữ liệu của chính mình.
• Những hậu quả dẫn đến MySQL bị treo, máy chủ chết hoàn toàn, dung lượng đĩa không còn trống, ngốn sạch băng thông. Chẳng hạn một record chừng 30kbytes thì 1000 hoặc 10000 cứ như vậy lặp đi lặp lại theo cấp số nhân thì dung lượng đĩa tốn khá nhiều cho những dữ liệu vô ích và CPU sẽ tải rất nhiều tài nguyên.

5. Flood process là gì?.

Là dạng Flood không tạo ra dữ liệu mới mà nó gửi những request khiến PHP và MySQL xử lý khá vất vả. Hiện đang có trào lưu Flood PHP và MySQL bằng X-flash Macro Media Flash. Minh chứng là các bạn thấy trang có nhiều trang hứng chịu một ngày trên cả trăm đợt tấn công, nhưng tại sao vẫn đứng hiên ngang, là do chế độ bảo mật cao, nếu đối với các Website thường thì có thể đã không còn tồn tại.

Cách phòng chống:

• Đối với Form nhập liệu thì cần tạo ra mã xác nhận dạng hình ảnh, có thể xem phần đăng ký thành viên tại PHPeasy, Hvanews...
• Cấu hình MySQL chấp nhận nhiều kết nối hơn, mặc định của MySQL là 100 connection.
• Thiết lập hệ thống Firewall lọc những header chứa X-Flash.
• Chuyển Website sang SSL.
• Còn nhiều cách khác nữa, ở đây mình chỉ đưa ra những nghiên cứu mang tính chủ quan và sưu tầm từ kinh nghiệm của các tiền bối.