laptrinhvtd
New Member
PHP là một ngôn ngữ lập trình mã nguồn mở đáp ứng cho sự phát triển web và sử dụng song song với mã HTML. Ngôn ngữ lập trình PHP có cách thức viết gẫn gũi với C và PERL , tuy nhiên PHP viết dễ dàng , không cầu kỳ như C hoặc PERL với cách đặt biến dễ chịu và tất cả kiến thức về học php cơ bản sẽ có trong giáo trình dạy thiết kế web bằng php.+ Dạng truyền biến:
Khi lập trình ta thường thấy nhiều lỗi do cách thức truyền biến ra IE hoặc Netcape do form . Khi submit một form nào đó , 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 còn có session và cookies .
Mỗi con đường truyền biến bao giờ cũng có cái lợi và các hại của nó . Ở đây xin đề cập đến vấn đề tác hại của nó.Khi một lập trình viên được đào tạo lập trìnhvới ngôn ngữ 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 bar address của các chương 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 và nguy hiểm là 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 .
Code ví dụ :
[/COLOR]
Code trên cho thấy nếu tồn tạn 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 source của bạn đã được tham khảo thì điều này coi như vô nghĩa – Sẽ được nói sau tại mục PHP exploit local ) .
Submit form với hình thức GET , thì các biến trong form 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 :
[/COLOR]
Xin được nói sơ về SQL injection với cách truyền biến này .
Ví dụ :
[/COLOR]
Nếu $osd trên address lộ ra như vậy : ORDER by id DESC Thì ta có thể thay thế biến osd với một giá trị khác là code PHP chẳng hạn . Vậy là chẳng khác nào 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ụ :
[/COLOR]
KHi bạn nhập ttext 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 .
Vâng ! Có khá nhiều cách , bạn có thể cookies , session hay hidden biến đó.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ụ :
Nếu bạn đặt một biến hidden nào đó dùng để check 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 CT duyệt web là lộ nguyên si . Và khi kẻ tấn công có thể tạo ra các biến đó thì … việc check mệnh đề 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 cũng nguy hiểm khôn lường : Tận dụng để nhúng ccác loại sâu bọ , Các đoạn mã chôm thông tin ( 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 set cookies các thông tin về một tài khoản nào đó thì … chỉ cần xem cookies là xong . Cách khắc phục là mã hóa nó hết .
Thứ 2 . Ví dụ một cookies sau đây:
[/COLOR]
Vấn đề ở đây là về việc chứa thông tin không cần thiết là password 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 … vẫn dịch ngược được và dạng MD5 thì vẫn có thể Brute Force .
Vậy cookies những gì cần thiết không nên chứa những thông tin mang tính bảo mật .
Đó là những lỗi cơ bản , vỉ thời gian có hạn , nên chỉ nêu một vài lỗi như thế .Safe mode PHP and MySQL local exploit ( 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ừ host chung server .
Ví dụ khi bạn có host ở server ABC và kẻ tấn công cũng có host chung server và chung ổ đĩ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 thì theo độ bảo mật của server đó . cụ thể như : xem source ( tìm lỗi bảo mật của lập trình ) ,xem thông tin tài khoảng host của bạn ( username , password , email ) , chiếm server , by pass server ……Xin được nói sơ về lỗi này:Chỉ cần 1 vài backdoor trên server là nguy hiểm không lường . Khi cơ sở dữ liệu của bạn dùng MySQL để lộ password , user của database thì việc sinh sát CDSL đó hoàn toàn có thể thực thi ( DROP , QUERY , INSERT … ) , và đặc biệt nguy hiểm đối với các server dùng Cpanel để quản lý hosting cho mỗi tài khoản . Một số Cpanel tạo db có info trùng với tài khoải login và 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 hắn với đầy đủ quyền hạn .Nếu PHP chạy trên Linux thì việc soi server tìm thông tin chỉ là việc đơn giản nhưng cũng tuỳ theo độ bảo mật của server đó. Tình hình hiện nay một số Công ty VN hosting 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 một cách an toàn .
Ngoài cách trên , 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ôĩ này : Apache chunk-ed Vul .Nguyên nhân xảy ra lỗi này :- Safe mode : được mở
- Các thư mục chưa được set quyền .
- Chưa setting cho php.ini kỹ .
- PHP cho phép set php.ini bất kỳ .
- MySQL cho phép truy xuất vào cơ sỡ dữ liệu với host chung : localhostDữ liệu từ form HTML
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 1 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 bạn lập trình đưa trực tiếp các biến vào thẳng CSDL mà không thông qua một bước kiểm tra nào đó thì nguy hiểm .
Các nguy hiểm có thể xảy ra :
- Cross site scripting
- SQL injection
- Buffer overflow in MySQL
Vì vậy bước kiểm tra các biến vào hết sức quan trọng .
Cách khắc phục :
- Cross site scripting : Để khắc phục lỗi này , 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 đó : str_replace , strip_tags , htmlspecialchars , htmlentities … ( tham khảo thêm về các hàm sử 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 nguy hiểm nếu “dính” dấu ‘ , “” hoặc # , vì thế cách khắc phục cũng như trên hoặc thêm hàm addslashes .
- Buffer overflow in MySQL : cái này thường nghiêm trọng , khi bạn đưa biến vào CSDL mà không chống flood thì kẻ tấn công cò thể fresh trình duyệt web hoặc dùng những script tấn côngf từ server , host hay localhost khác , làm tràn server . Khiến tắt nghẽn … và server có thể cắt host bạn như chơi . Cách khắc phục , so sánh biến nhập vào trùng hay thơi gian … nói chung có nhiều cách để làm việc này , hiệu quả và nhanh thì dùng hàm header sau khi submit . ( Nếu bạn lập trình dùng hàm MySQL_fetch_array , cũng dễ bị tràn server , lý do gôm dữ liệu vào mảng nếu nhiều record thì thế nào … vì thế bạn có thể chuyển qua dùng MySQL_result , nó lấy dữ liệu theo filed và column )
Lưu ý 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 file gì khi được upload vì không sẽ có thể làm host của bạn dính backdoor .
Khi lập trình ta thường thấy nhiều lỗi do cách thức truyền biến ra IE hoặc Netcape do form . Khi submit một form nào đó , 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 còn có session và cookies .
Mỗi con đường truyền biến bao giờ cũng có cái lợi và các hại của nó . Ở đây xin đề cập đến vấn đề tác hại của nó.Khi một lập trình viên được đào tạo lập trìnhvới ngôn ngữ 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 bar address của các chương 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 và nguy hiểm là 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 .
Code ví dụ :
[COLOR=white !important]
?
1 | if ($hello) echo "hello"; |
[/COLOR]
Code trên cho thấy nếu tồn tạn 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 source của bạn đã được tham khảo thì điều này coi như vô nghĩa – Sẽ được nói sau tại mục PHP exploit local ) .
Submit form với hình thức GET , thì các biến trong form 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 :
[COLOR=white !important]
?
1 2 3 4 | <form name="test" action="" method=GET> <input name="key" type=text> <input type=submit value="Test"> </form> |
[/COLOR]
Xin được nói sơ về SQL injection với cách truyền biến này .
Ví dụ :
[COLOR=white !important]
?
1 | $a = MySQL_query("SELECT * FROM user $osd"); |
[/COLOR]
Nếu $osd trên address lộ ra như vậy : ORDER by id DESC Thì ta có thể thay thế biến osd với một giá trị khác là code PHP chẳng hạn . Vậy là chẳng khác nào 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ụ :
[COLOR=white !important]
?
1 | $osd="); MySQL_query("INSERT INTO user ....."); |
[/COLOR]
KHi bạn nhập ttext 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 .
Vâng ! Có khá nhiều cách , bạn có thể cookies , session hay hidden biến đó.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ụ :
Nếu bạn đặt một biến hidden nào đó dùng để check 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 CT duyệt web là lộ nguyên si . Và khi kẻ tấn công có thể tạo ra các biến đó thì … việc check mệnh đề 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 cũng nguy hiểm khôn lường : Tận dụng để nhúng ccác loại sâu bọ , Các đoạn mã chôm thông tin ( 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 set cookies các thông tin về một tài khoản nào đó thì … chỉ cần xem cookies là xong . Cách khắc phục là mã hóa nó hết .
Thứ 2 . Ví dụ một cookies sau đây:
[COLOR=white !important]
?
1 2 | userid=11 passhash="helloall" |
[/COLOR]
Vấn đề ở đây là về việc chứa thông tin không cần thiết là password 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 … vẫn dịch ngược được và dạng MD5 thì vẫn có thể Brute Force .
Vậy cookies những gì cần thiết không nên chứa những thông tin mang tính bảo mật .
Đó là những lỗi cơ bản , vỉ thời gian có hạn , nên chỉ nêu một vài lỗi như thế .Safe mode PHP and MySQL local exploit ( 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ừ host chung server .
Ví dụ khi bạn có host ở server ABC và kẻ tấn công cũng có host chung server và chung ổ đĩ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 thì theo độ bảo mật của server đó . cụ thể như : xem source ( tìm lỗi bảo mật của lập trình ) ,xem thông tin tài khoảng host của bạn ( username , password , email ) , chiếm server , by pass server ……Xin được nói sơ về lỗi này:Chỉ cần 1 vài backdoor trên server là nguy hiểm không lường . Khi cơ sở dữ liệu của bạn dùng MySQL để lộ password , user của database thì việc sinh sát CDSL đó hoàn toàn có thể thực thi ( DROP , QUERY , INSERT … ) , và đặc biệt nguy hiểm đối với các server dùng Cpanel để quản lý hosting cho mỗi tài khoản . Một số Cpanel tạo db có info trùng với tài khoải login và 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 hắn với đầy đủ quyền hạn .Nếu PHP chạy trên Linux thì việc soi server tìm thông tin chỉ là việc đơn giản nhưng cũng tuỳ theo độ bảo mật của server đó. Tình hình hiện nay một số Công ty VN hosting 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 một cách an toàn .
Ngoài cách trên , 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ôĩ này : Apache chunk-ed Vul .Nguyên nhân xảy ra lỗi này :- Safe mode : được mở
- Các thư mục chưa được set quyền .
- Chưa setting cho php.ini kỹ .
- PHP cho phép set php.ini bất kỳ .
- MySQL cho phép truy xuất vào cơ sỡ dữ liệu với host chung : localhostDữ liệu từ form HTML
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 1 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 bạn lập trình đưa trực tiếp các biến vào thẳng CSDL mà không thông qua một bước kiểm tra nào đó thì nguy hiểm .
Các nguy hiểm có thể xảy ra :
- Cross site scripting
- SQL injection
- Buffer overflow in MySQL
Vì vậy bước kiểm tra các biến vào hết sức quan trọng .
Cách khắc phục :
- Cross site scripting : Để khắc phục lỗi này , 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 đó : str_replace , strip_tags , htmlspecialchars , htmlentities … ( tham khảo thêm về các hàm sử 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 nguy hiểm nếu “dính” dấu ‘ , “” hoặc # , vì thế cách khắc phục cũng như trên hoặc thêm hàm addslashes .
- Buffer overflow in MySQL : cái này thường nghiêm trọng , khi bạn đưa biến vào CSDL mà không chống flood thì kẻ tấn công cò thể fresh trình duyệt web hoặc dùng những script tấn côngf từ server , host hay localhost khác , làm tràn server . Khiến tắt nghẽn … và server có thể cắt host bạn như chơi . Cách khắc phục , so sánh biến nhập vào trùng hay thơi gian … nói chung có nhiều cách để làm việc này , hiệu quả và nhanh thì dùng hàm header sau khi submit . ( Nếu bạn lập trình dùng hàm MySQL_fetch_array , cũng dễ bị tràn server , lý do gôm dữ liệu vào mảng nếu nhiều record thì thế nào … vì thế bạn có thể chuyển qua dùng MySQL_result , nó lấy dữ liệu theo filed và column )
Lưu ý 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 file gì khi được upload vì không sẽ có thể làm host của bạn dính backdoor .