|
|
@bietchetlien007: bạn đang có những nhầm lẫn căn bản và khá chết người. Nguy hại hơn, bạn đang "áp đặt" cái nhầm lẫn đó vào topic, người ngoài đã "định hướng" cho bạn mà bạn vẫn còn "cố chấp" như thế!
1. SQL Inj không lệ thuộc vào 1 ngôn ngữ lập trình nào, PHP, ASP, JSP v.v...đều có thể bị dính lỗi SQL Inj nếu developer bất cẩn
==> bạn "cứ cho" là server chạy PHP là 1 "cố chấp được áp đặt" thứ nhất.
2. SQL Inj không lệ thuộc vào HDH hay CSDL. Win/Linux, Apache/IIS, MYSQL/MSSQL...đều có thể bị dính lỗi SQL Inj cả.
3. Bạn "áp đặt" SQL Inj với IIS/PHP rồi up shell, run command...để làm gì?
Trong khi từ những cái căn bản và sơ khai nhất là SQL Inj ta có thể có vô vàn cách khai khác khác nhau.
Không phải cứ up được shell, hay chạy được command thì mới gọi là hack!!!
Bạn cứ "cố chấp" như thế sẽ chả đi đến đâu! Trong khi từ cái sơ khởi là SQL Inj, nếu bình tĩnh, sáng suốt và có óc sáng tạo sẽ có thể làm được nhiều cái hay ho mà không cần gì phải upload shell hay execute command cả.
|
|
|
conmale wrote:
Bắt đầu từ đây:
http://java.sun.com/docs/books/tutorial/index.html
và quên đi ý định tìm tài liệu tiếng Việt nếu như muốn đi sâu và thành công với việc học Java.
Hì hì, nói chung học lập trình muốn lên hàng "cao thủ" thì nên quên đi vụ tiếng Việt chứ không riêng gì Java
|
|
|
Fal tham khảo thêm link này:
http://www.diendantinhoc.net/tute/laptrinh/perl/learningperl/ch_07.html
Và các link về RE trong PHP (lưu ý, PHP hỗ trợ 2 loại syntax/lib regexp khác nhau!)
để làm tài liệu tham khảo cho các phần sau của bài viết
|
|
|
Một hồi rồi tự nhiên sang bảo mật PHP. Không lẽ trên đời này chỉ có mình PHP là viết được shell?
|
|
|
conmale wrote:
mrro wrote:
Đương nhiên xây dựng một hệ thống như thế đòi hỏi tiền bạc, thời gian, nhân lực và rõ ràng là không thể áp dụng cho HVAOnline.
- đối với một hệ thống như HVAOnline, chúng ta có thể điều chỉnh bằng các rule, chẳng hạn như:
+ ủy thác thực hiện các chức năng quan trọng vào một lớp IP nhất định.
+ trước khi thực hiện bất kỳ chức năng nào, phải verify lại mật khẩu.
+ tách bạch giữa account quản lý và account sinh hoạt trên diễn đàn (chẳng hạn như "quanlytruong")
+ ...
Điểm thứ 1 ok, đã áp dụng (như điểm thứ 3).
Điểm thứ 2 hơi kẹt .
Điểm thứ 3 gần giống điểm thứ 1.
Hầu hết các chức năng quan trọng đều nằm trong administrator account và nó được "quản chế" khá chặt. Các account moderators có thể làm được một số công tác quan trọng khác nhưng không thể làm hàng loạt được . Đây là nguyên tắc bảo mật căn bản.
Điểm thứ 2 của Thái không phải là không hữu dụng. Mình có thể chia ra làm 2 cấp:
* Cấp đầu tiên: Mọi action "nguy hiểm" đều phải qua 1 bước đệm để confirm, và action cuối cùng chỉ được thực hiện thông qua 1 POST request. Ví dụ, khi xóa bài viết, thay vì hiển thị lên cái pop-up javascript "Are you sure?", thì mình làm 1 page Confirm "Are you sure?" từ server side. Và khi click "Yes" sẽ POST request lên server. Cách làm này có nhiều lợi điểm:
- Không giảm thiểu mấy về mặt tiện dụng. Hiện thêm 1 cái confirmation để hỏi Yes/No cho các tác vụ nguy hiểm như delete chẳng hạn thì sẽ không có ai than phiền gì đâu; mà có khi còn được hoan nghênh nữa là khác
- Cản được khá nhiều các tấn công kiểu cross-site. Vì thứ nhất wwwect trong HTTP không hỗ trợ POST; sẽ giảm thiểu được kiểu tấn công bằng cách wwwect qua/lại giữa các node (pc của hva user, server hva, server/pc của attacker). Thứ hai, mình có thể lợi dụng cái trang confirmation đệm ở giữa này để tạo 1 security token riêng cho cái action đó; như vậy attacker có send được 1 cái POST request đến server HVA thì cũng gặp khó khăn hơn vì cái security token này attacker cũng khó mà có được.
* Cấp thứ 2 là làm thêm 1 ô verify password ở cái trang "Are you sure?". Xét về mặt tiện dụng thì có hơi bất tiện 1 chút. Nhưng giả sử với 1 action nguy hiểm như "delete sạch 1 box của diễn đàn (và có thể các box con của nó)" thì thêm 1 ô verify password cũng đâu có gì là quá đáng
Và cái điểm thứ 2 của Thái này anh Diêu cũng đã dùng 5-6 năm nay ở diễn đàn mình rồi (mọi tác vụ đều phải nhập username/password và POST), có gì "kẹt" đâu
Tuy nhiên, kiểu gì thì kiểu nhưng vẫn không thể nào hoàn hảo được. Mình phải chấp nhận sự cân bằng giữa nhiều yếu tố ở mức độ nào đó mà thôi.
P/S: Có ai thử làm post 1 bài viết trên forum HVA mà muốn xóa nó sẽ rất cực, thậm chí có thể gần như không xóa được nó nếu không biết cái trick
Cho tới thời điểm post bài, HVA vẫn bị "lỗi" này. "Lỗi" này "phá chơi" cho vui chứ không hại gì nhiều. Mà cũng rất dễ làm
|
|
|
Giỏi thì không có gì phải lo.
Chứ còn kiểu học cái này 1 nút, mai "nghe nói" cái kia ngon hơn thì chạy theo học 1 ít, mốt lại qua học cái khác 1 ít thì lúc nào cũng sẽ thấy lo thôi
|
|
|
Zip lại nguyên thư mục, truyền đi, qua đầu kia unzip là có ngay cấu trúc thư mục
|
|
|
Điều này chứng tỏ vì lý do nào đó mà con mèo Tom xài hết 200 threads cho phép.
Có vẻ có 1 lỗi gì đó ở tomcat (hoặc mod_jk?). Vào những lúc như thế server load khá thấp (chỉ 0.x). Nhưng toàn bộ request vào Tomcat đều bị queued hoặc dropped vì không còn available thread nào để xử lý. Mà toàn bộ các thread lúc đó bị tình trạng giống như "zombie": không xử lý gì hết (server load thấp), nhưng lại bị marked là in-used. Restart lại Tomcat thì hết bị.
|
|
|
Chức năng thì chưa biết tốt hay không nhưng đầu tiên có 1 điểm đáng khen là dùng thư viện của ai đều có nêu rõ. Cái này rất là đáng khen
|
|
|
SuperChicken wrote:
Mình vẫn thấy kỳ, đọc đi đọc lại 2-3 lượt vẫn thấy chủ topic không đả động gì đến mod_rewrite, chỉ hỏi là làm sao sử dụng được file .htaccess cho Plesk + IIS (không lẽ GA đánh đồng file .htaccess với mod_rewrite).
*PS: Sao lại có cái "Cùi bắp đại ca" chỗ location thế? Cái nick đó là của 1 đồng nghiệp trong cty tớ, không lẽ cậu là...
Vì thế nào câu hỏi cũng sẽ dẫn đến mod_rewrite (và thực tế đã chứng minh như thế ), nên GA trả lời luôn về mod_rewrite cho nó tiện đó mà
|
|
|
Mục đích của việc lắp 1 mạng như thế là gì? Và bạn muốn đạt được điều gì?
Nếu vì PC 2 và 3 cách xa PC1 thì chỉ cần thêm 1 switch để nối ở giữa trung gian là được, cần gì phải thêm 1 modem và kéo thêm 1 đường internet làm gì?
|
|
|
Đọc sách = học
Thực tập = hành
Vừa có học vừa có hành còn đòi gì nữa trời!
|
|
|
Những cái thuộc về kỹ thuật và kỹ năng lập trình (OOP, Design Patterns, Best Practices...) thì kiếm cuốn sách hoặc ebook về đọc và nghiền ngẫm mấy cái ví dụ của nó. Khỏi cần đi học cũng được vì mấy cái này lý thuyết nó đã rõ ràng quá rồi, chỉ cần chịu khó đọc + siêng thực hành là được. Và tốt hơn hết là đọc tài liệu nguyên gốc tiếng Anh
Mấy món nặng đô hơn như software architect, system architect...thì rất tiếc là ở VN hiện tại chỉ có thể kiếm sách về đọc để tiếp thu được chút gì thì tiếp thu chứ còn đi học thì e rằng ở VN hiện tại không có nơi nào đủ sức dạy cho đúng nghĩa.
Một hệ thống "nặng đô" nhiều khi phải sống được 5, 10, 20 năm hoặc thậm chí hơn. Phải có tính mở rộng và scale được về nhiều mặt. Nền công nghiệp phần mềm ở VN đã đủ bề dày lịch sử bao nhiêu năm đó chưa để có thể kinh qua hết những cái ở mức enterprise level?
Bạn viết 1 hệ thống chạy được, người ta cũng viết hệ thống chạy được. Nhưng của người ta bự, phức tạp và có vẻ cồng kềnh hơn của bạn gấp mấy lần
--> trường hợp đầu là bạn có thể chê là sao người ta làm phức tạp hóa vấn đề quá
--> trường hợp thứ 2 là có thể bạn không hiểu được là tại sao người ta lại phải làm cồng kềnh phức tạp như thế.
Phải đến 1 thời gian sau mới thấy rõ được sự khác biệt giữa bạn và người ta
Có khi bạn chặt lưỡi: ôi dào, 5-10 năm sau thì dư thời gian để viết tiếp cái system khác hoặc cài tiến cái system hiện tại cho tốt hơn. Ờ, cứ cho là thế đi, nhưng xét về khía cạnh người ta "20 năm vẫn chạy tốt", còn bạn "vài năm phải thay mới 1 lần" thì đủ thấy ai hơn ai rồi.
|
|
|
Em chưa thấy cái website nào chạy được Multi-threading processing cả .
Website nào mà chả là multi-thread Vì bản thân cái web server là multi-thread rồi, nhiều request tới đồng thời nó vẫn xử lý được.
Còn bên trong 1 request mà trang web tạo ra nhiều thread con để xử lý thì...đầu tiên phải hỏi là: để làm gì đã.
|
|
|
PHP thì chỉ có cách là lưu trong database (hoặc 1 nơi cố định nào đó như file trên đĩa, tuy nhiên so với lưu file trên đĩa thì lưu trong DB lợi hơn nhiều). Hoặc nếu server có memcached hay APC thì dùng cũng được (lúc này sẽ lưu trong 1 vùng memory chung mà các request đều truy cập được).
Java (Servlet) như cách anh conmale thì có thể lưu trong memory vì bản thân các request đến server đều có thể chỉ do 1 servlet đảm nhiệm --> dùng memory chung được; thậm chí giữa nhiều servlet cũng có thể share được memory.
|
|
|
Đi làm 1 cty IT thì vẫn có thể học thêm 1 bằng cao học Anh ngữ vào buổi tối mà!
Đi học cao học chứ có phải học như ĐH đâu mà tuần phải 5 buổi cắp sách đến trường nghe thầy đọc gì chép nấy.
|
|
|
ATACK wrote:
Mình muốn tìm hiểu viề Linux nên có cài RetHat EnterPrise Linux 5!
"Muốn tìm hiểu" tức là mới làm quen? Mới làm quen mà chơi tận RetHat EnterPrise Linux 5
==> lời khuyên: kiếm bản Linux nào phổ thông và "nhẹ" đô hơn chút về xài! Ví dụ: Fedora Core, Ubuntu, v.v...
|
|
|
Cài 1 chương trình tạo máy ảo vô (VMWare chẳng hạn) rồi muốn mấy chục cái máy Linux cũng được.
|
|