[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 03:24:56 (+0700) | #61 | 118216 |
|
secmask
Elite Member
|
0 |
|
|
Joined: 29/10/2004 13:52:24
Messages: 553
Location: graveyard
Offline
|
|
gamma95 wrote:
conmale wrote:
Khơi thêm một tí để bàn cho vui
Giả sử chúng ta có một trường hợp xử lý như sau:
1) User A gởi request thứ nhất đến HVA và chưa hề nhận được một cookie nào cả.
2) HVA trả lời request thứ nhất này đồng thời set một cookie "đặc biệt" trên trình duyệt của user A. Tạm gọi cookie này là cookie=1
3) User A gởi request thứ nhì đến HVA, request này có kèm theo cookie=1. Ở bước này HVA sẽ tiếp nhận request thứ nhì của user A nếu như nó có kèm theo cookie=1. Nếu không, nó sẽ từ chối trả lời. Nếu HVA tiếp nhận request thứ nhì này (vì nó có kèm theo cookie=1), HVA sẽ tiếp tục set một cookie khác đến trình duyệt của user A. Tạm gọi là cookie=2 (cookie=1 đã bị hủy).
Cứ như thế, mỗi request từ user A phải kèm theo một cookie mới nhất và có giá trị được HVA set ở lần request gần nhất trước đây và request ấy chỉ được trả lời nếu như nó có cookie mới nhất và có giá trị.
Với cơ chế như trên, giả sử user B bằng cách nào đó "chôm" được cookie của user A (cứ cho rằng user B chôm được trọn bộ HTTP header của user A). Liệu user B có thể làm được gì với cookie lấy được? Tại sao? Tại sao không?
Mời bà con bàn.
Thân.
Theo em thằng Thằng User B nó vẫn exploit bình thường vì nó đã tóm được cookie thứ N ( là mới nhất) sau đó nó nhanh tay thực hiện một cú request khác đến HVA để lấy cái Cookie thứ N+1. Tại sao phải nhanh tay, vì nếu không nhanh tay thì thằng Victim A sau khi bị mất Cookie thứ N nó duyệt một link khác trên HVA thì Cookie thứ N của thằng Hacker B trở nên vô giá trị . Đây cũng là một trong những phương pháp tốt để chống kiểu tấn công "Session fixation"
nếu bên client thêm 1 đoạn javascript connect đến hva để nhận sessionID mới thì sao nhỉ ?, sau khoảng thời gian delay phù hợp nào đó ? |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 03:45:26 (+0700) | #62 | 118219 |
|
gamma95
Researcher
|
Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline
|
|
@secmask: tui có nói đến cụm từ "nhanh tay" , còn chuyện một đoạn javascript để connect đến HVA trong khoảng thời gian delay nào đó ... thì attacker có thể disable đoạn script đó cũng bằng "XSS exploit ". Cụ thể là một đoạn javascript set lại thời gian delay phía victim ( hoặc Disable luôn) sau đó mới chôm cookie bình thường |
|
Cánh chym không mỏi
lol |
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 04:34:32 (+0700) | #63 | 118231 |
boom_jt
Member
|
0 |
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
Cách của bác conmale có thể bypass 1 cách đơn giản thế này (không cần phải nhanh tay ha ) : khi server của người tấn công nhận đc cookie mới nhất của victim, nó tự động liền sau đó gửi yêu cầu tới web server với http header và cookie của victim để lấy về cookie "mới hơn nữa" như vậy kẻ tấn công sẽ chiếm đc 1 cookie hợp lệ, đồng thời biến cookie đang lưu trong browser nạn nhân trở thành bất hợp lệ. Và thông thường boom_jt thấy thì nạn nhân có login lại thì cookie của kẻ tấn công cũng không trở thành bất hợp lệ do sự cho phép nhiều người dùng đăng nhập vào cùng 1 tài khoản.
Vậy làm sao để hạn chế việc này?
1. Chỉ cho phép 1 người dùng đăng nhập vào 1 tài khoản trong 1 thời điểm, và cookie đc set khi đăng nhập thành công sẽ là cookie hợp lệ. tất nhiên điều này kéo theo 1 vài ràng buộc nào đó liên quan đến yêu cầu phần mềm, nói chung là cũng còn tùy trường hợp. Trong trường hợp HVA forum thì có lẽ cơ chế này có thể áp dụng
2. Dựa trên cách bác conmale đề ra: sử dụng 1 cookie SID không đổi (session) và cookie động (giống như của bác conmale). Chỉ cần cookie động không hợp lệ là SID sẽ bị loại bỏ luôn. Như thế, khi nạn nhân sử dụng cookie "không còn hợp lệ" (do cách khai thác ở trên) để tạo kết nối tiếp theo cũng đồng nghĩa với việc biến cookie "hợp lệ" đang nằm trong tay kẻ tấn công thành bất hợp lệ. Nạn nhân sẽ phải đăng nhập lại để có cookie hợp lệ.
Tuy nhiên, với cách 2 như vừa nêu, giả sử lỗi XSS nằm ngay tại index của diễn đàn (hay trong danh sách thành viên online chẳng hạn), sẽ dẫn đến 1 vấn đề là toàn bộ thành viên sẽ ko thể vào đc diễn đàn, vì cookie của họ liên tục trở thành bất hợp lệ!
Phương pháp nào cũng có mặt trái của nó kèm theo đó là 1 số bất cập do các bác đã nêu...
thân mến |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server |
07/03/2008 04:46:06 (+0700) | #64 | 118235 |
|
gamma95
Researcher
|
Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline
|
|
@boom_it: đồng chí nói rõ cái công nghệ "tự động gởi tới webserver" đc ko? |
|
Cánh chym không mỏi
lol |
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 05:08:39 (+0700) | #65 | 118244 |
|
vivashadow
Member
|
0 |
|
|
Joined: 08/01/2008 12:36:49
Messages: 95
Offline
|
|
gamma95 wrote:
@secmask: tui có nói đến cụm từ "nhanh tay" , còn chuyện một đoạn javascript để connect đến HVA trong khoảng thời gian delay nào đó ... thì attacker có thể disable đoạn script đó cũng bằng "XSS exploit ". Cụ thể là một đoạn javascript set lại thời gian delay phía victim ( hoặc Disable luôn) sau đó mới chôm cookie bình thường
Hiện tại HVA có dùng 1 iframe ở cuối để ping về HVA sau interval 600s, có thể kết hợp cái này để làm mới cookie mà không cần đoạn javascrip secmask nói. |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 05:30:23 (+0700) | #66 | 118255 |
boom_jt
Member
|
0 |
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 05:42:50 (+0700) | #67 | 118257 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
boom_jt wrote:
Cách của bác conmale có thể bypass 1 cách đơn giản thế này (không cần phải nhanh tay ha ) : khi server của người tấn công nhận đc cookie mới nhất của victim, nó tự động liền sau đó gửi yêu cầu tới web server với http header và cookie của victim để lấy về cookie "mới hơn nữa" như vậy kẻ tấn công sẽ chiếm đc 1 cookie hợp lệ, đồng thời biến cookie đang lưu trong browser nạn nhân trở thành bất hợp lệ. Và thông thường boom_jt thấy thì nạn nhân có login lại thì cookie của kẻ tấn công cũng không trở thành bất hợp lệ do sự cho phép nhiều người dùng đăng nhập vào cùng 1 tài khoản.
Nếu không nhanh tay thì làm sao có thể tiếp tục dùng cookie chôm được để gởi request đến HVA server để lấy cookie mới? Nếu kẻ tấn công cần thời gian để setup và để có thể dùng cookie chôm được, lúc ấy có thể cookie mới đã được cấp đến victim rồi và cookie chôm được trở thành vô dụng. Cái quan trọng là động tác "tự động liền sau đó gửi yêu cầu tới web server với http header và cookie của victim để lấy về cookie" thực hiện như thế nào.
Nên nhớ rằng, các phương pháp xss hiện giờ chưa có cách nào khả dĩ để có thể "tự động gởi yêu cầu đến server bằng cookie chôm được" với thời gian đủ nhanh. Chỉ có một khả năng có thể khai thác khá bảo đảm là sau khi bị chôm mất cookie, victim vẫn không làm gì tiếp để cập nhật cookie mới (đứng idle).
boom_jt wrote:
Vậy làm sao để hạn chế việc này?
1. Chỉ cho phép 1 người dùng đăng nhập vào 1 tài khoản trong 1 thời điểm, và cookie đc set khi đăng nhập thành công sẽ là cookie hợp lệ. tất nhiên điều này kéo theo 1 vài ràng buộc nào đó liên quan đến yêu cầu phần mềm, nói chung là cũng còn tùy trường hợp. Trong trường hợp HVA forum thì có lẽ cơ chế này có thể áp dụng
HVA forum chưa bao giờ cho phép 1 tài khoản có thể login ở 2 thời điểm khác nhau song song nhau. Chỉ có thể có một xuất đăng nhập tồn tại trong một thời điểm mà thôi.
boom_jt wrote:
2. Dựa trên cách bác conmale đề ra: sử dụng 1 cookie SID không đổi (session) và cookie động (giống như của bác conmale). Chỉ cần cookie động không hợp lệ là SID sẽ bị loại bỏ luôn. Như thế, khi nạn nhân sử dụng cookie "không còn hợp lệ" (do cách khai thác ở trên) để tạo kết nối tiếp theo cũng đồng nghĩa với việc biến cookie "hợp lệ" đang nằm trong tay kẻ tấn công thành bất hợp lệ. Nạn nhân sẽ phải đăng nhập lại để có cookie hợp lệ.
Logic là thế.
boom_jt wrote:
Tuy nhiên, với cách 2 như vừa nêu, giả sử lỗi XSS nằm ngay tại index của diễn đàn (hay trong danh sách thành viên online chẳng hạn), sẽ dẫn đến 1 vấn đề là toàn bộ thành viên sẽ ko thể vào đc diễn đàn, vì cookie của họ liên tục trở thành bất hợp lệ!
Phương pháp nào cũng có mặt trái của nó kèm theo đó là 1 số bất cập do các bác đã nêu...
thân mến
Nếu như session của kẻ tấn công có yếu tố nào đó giúp phân biệt được và chính session (của người thực hiện hijack) ấy bị hủy chớ không phải session của người bị hijack bị hủy thì sao? . |
|
What bringing us together is stronger than what pulling us apart. |
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 05:53:10 (+0700) | #68 | 118261 |
|
gamma95
Researcher
|
Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline
|
|
vivashadow wrote:
gamma95 wrote:
@secmask: tui có nói đến cụm từ "nhanh tay" , còn chuyện một đoạn javascript để connect đến HVA trong khoảng thời gian delay nào đó ... thì attacker có thể disable đoạn script đó cũng bằng "XSS exploit ". Cụ thể là một đoạn javascript set lại thời gian delay phía victim ( hoặc Disable luôn) sau đó mới chôm cookie bình thường
Hiện tại HVA có dùng 1 iframe ở cuối để ping về HVA sau interval 600s, có thể kết hợp cái này để làm mới cookie mà không cần đoạn javascrip secmask nói.
@vivashadow:
Attacker dễ dàng inject cái script này để disable nguyên đoạn mã html phía dưới, trong đó có cả cái iframe chứa ping.jsp của HVA
<script>window.open() .....</script><!--
Cách của bác conmale có thể bypass 1 cách đơn giản thế này (không cần phải nhanh tay ha ) : khi server của người tấn công nhận đc cookie mới nhất của victim, nó tự động liền sau đó gửi yêu cầu tới web server với http header và cookie của victim để lấy về cookie "mới hơn nữa" như vậy kẻ tấn công sẽ chiếm đc 1 cookie hợp lệ, đồng thời biến cookie đang lưu trong browser nạn nhân trở thành bất hợp lệ. Và thông thường boom_jt thấy thì nạn nhân có login lại thì cookie của kẻ tấn công cũng không trở thành bất hợp lệ do sự cho phép nhiều người dùng đăng nhập vào cùng 1 tài khoản.
Nếu không nhanh tay thì làm sao có thể tiếp tục dùng cookie chôm được để gởi request đến HVA server để lấy cookie mới? Nếu kẻ tấn công cần thời gian để setup và để có thể dùng cookie chôm được, lúc ấy có thể cookie mới đã được cấp đến victim rồi và cookie chôm được trở thành vô dụng. Cái quan trọng là động tác "tự động liền sau đó gửi yêu cầu tới web server với http header và cookie của victim để lấy về cookie" thực hiện như thế nào.
@boom_it: ý anh conmale cũng là ý tui muốn hỏi, nếu có thể bạn có thể viết một đoạn mã nhỏ (PoC) để demo thử.
|
|
Cánh chym không mỏi
lol |
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 06:51:37 (+0700) | #69 | 118277 |
boom_jt
Member
|
0 |
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
Phải nói rõ ràng thêm 1 chút thế này: khi boom_jt nói "không cần nhanh tay" là ý nhấn mạnh vào từ "tay" - muốn nói do đã có script tự động thực hiện hộ việc làm bằng tay của kẻ tấn công để chiếm đc cookie hợp lệ tiếp theo rồi, chứ ko có ý nhấn mạnh vào đoạn "không cần nhanh"
conmale wrote:
Nên nhớ rằng, các phương pháp xss hiện giờ chưa có cách nào khả dĩ để có thể "tự động gởi yêu cầu đến server bằng cookie chôm được" với thời gian đủ nhanh.
Việc "tự động gởi yêu cầu đến server bằng cookie chôm được" đc thực hiện trên server của kẻ tấn công, và nó hoàn toàn không liên quan đến khả năng của XSS hay ko ^_^
Có thể ví dụ 1 chút thế này:
Filename: conmale_gamma95.php
Code:
...
$user_agent = $_SERVER['HTTP_USER_AGENT'];
... // lưu các giá trị nhận đc vào các biến
$ch = curl_init('/hvaonline/recentTopics/list.html');
curl_setopt($ch, CURLOPT_USERAGENT, $user_agent);
... // set đầy đủ các thuộc tính thu đc từ http header
curl_setopt($ch, CURLOPT_COOKIE, $cookie);
$res = curl_exec($ch); //thực hiện kết nối tới HVA bằng cookie vừa nhận đc
curl_close($ch);
SaveCookie($res) //thực hiện việc lưu cookie mới nhận đc trong kết quả trả về
(xin thứ lỗi cho boom_jt vì đoạn code trên mang tính chất cực kì "PoC", vì boom_jt ko thật rành lập trình cho đúng syntax á :">
Vậy đoạn mã khai thác XSS có thể khiến browser nạn nhân kết nối tới địa chỉ:
Code:
http://host/conmale_gamma95.php
Vậy khi đó, việc của conmale_gamma95.php là kết nối tới /hvaonline/recentTopics/list.html để lấy cookie mới và lưu nó lại.
thân mến
p/s
conmale wrote:
Nếu như session của kẻ tấn công có yếu tố nào đó giúp phân biệt được và chính session (của người thực hiện hijack) ấy bị hủy chớ không phải session của người bị hijack bị hủy thì sao?
hiện tại boom_jt chưa nghĩ ra, mong bác conmale chỉ giáo |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 07:05:00 (+0700) | #70 | 118281 |
|
ThíchHắcKinh
Member
|
0 |
|
|
Joined: 05/11/2007 21:56:23
Messages: 85
Location: Thiếu Lâm Tự
Offline
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server |
07/03/2008 07:07:35 (+0700) | #71 | 118282 |
|
gamma95
Researcher
|
Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline
|
|
@boom_it: đoạn mã cậu post lên tui chưa thấy tính tự động ở đâu cả. Cái tự động ở đây theo ý tui là ngay khi cái file log.txt nhận được cookie được gởi đến bởi nạn nhân thì ngay lập tức nó lấy giá trị cookie + HTTP header đó generate ra một http request đến server HVA ngay lập tức để lấy cookie mới kìa |
|
Cánh chym không mỏi
lol |
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 07:09:02 (+0700) | #72 | 118285 |
boom_jt
Member
|
0 |
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
hì hì, do bạn chưa đọc toàn bộ thread rồi, ý kiến bạn vừa nêu chính là liên quan tới http header đó |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 07:12:06 (+0700) | #73 | 118287 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
|
What bringing us together is stronger than what pulling us apart. |
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 07:20:15 (+0700) | #74 | 118290 |
|
ThíchHắcKinh
Member
|
0 |
|
|
Joined: 05/11/2007 21:56:23
Messages: 85
Location: Thiếu Lâm Tự
Offline
|
|
gamma95 wrote:
@boom_it: đoạn mã cậu post lên tui chưa thấy tính tự động ở đâu cả. Cái tự động ở đây theo ý tui là ngay khi cái file log.txt nhận được cookie được gởi đến bởi nạn nhân thì ngay lập tức nó lấy giá trị cookie + HTTP header đó generate ra một http request đến server HVA ngay lập tức để lấy cookie mới kìa
Chị gammar95 ạ ...đoạn code trên của boom_it chỉ mang tính tham khảo, vấn đề gởi request tự động khi thu thập được header + session của nạn nhân dễ dàng thực hiện được nếu dùng socket trong PHP ... đoạn code sau cũng mang tính tham khảo
Code:
<?php
function getURL(){
error_reporting(E_ALL);
$filenameurl = "urlip.txt"; //the default blog file
$sReponse="heheheheh";
//echo "<h2>TCP/IP Connection</h2>\n";
/* Get the port for the WWW service. */
$service_port = getservbyname('www', 'tcp');
/* Get the IP address for the target host. */
$address = gethostbyname('www.hvaonline.net/......'); //gì gì đó
/* Create a TCP/IP socket. */
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
if ($socket === false) {
//echo "socket_create() failed: reason: " . socket_strerror(socket_last_error()) . "\n";
} else {
//echo "OK.\n";
}
//echo "Attempting to connect to '$address' on port '$service_port'...";
$result = socket_connect($socket, $address, $service_port);
if ($result === false) {
//echo "socket_connect() failed.\nReason: ($result) " . socket_strerror(socket_last_error($socket)) . "\n";
} else {
//echo "OK.\n";
}
$in = "GET /hvaonline/posts/reply/0/15621.html HTTP/1.1\r\n"; /// ... gì gì đó
$in .= "Host:www.hvaonline.net\r\n";
//chỗ này chèn thông tin thu thập gì gì đó
//..
//..
$in .= "Connection: Close\r\n\r\n";
$out = '';
//echo "Sending HTTP HEAD request...";
socket_write($socket, $in, strlen($in));
//echo "OK.\n";
//echo "Reading response:\n\n";
while ($out = socket_read($socket, 2048)) {
//echo $out;
$sReponse .= $out;
}
//echo "Closing socket...";
socket_close($socket);
//echo "OK.\n\n";
if (file_exists("$filenameurl")) {
$fp = fopen($filenameurl,"a+");
fputs($fp,"==========\n".$sReponse."\n==========\n");
fclose($fp);
}
}
@conmale : Nếu vậy thì phải suy nghĩ thêm chút nữa đã |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 07:25:54 (+0700) | #75 | 118293 |
|
gamma95
Researcher
|
Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline
|
|
@long3ta: chuyện này tui biết chứ , và tất nhiên là làm được. Nhưng cái tui cần là các bác demo hoàn chỉnh kìa . Dùng phương pháp ghi $cookie, $http_header ra file log.txt rồi mới đọc vào rồi generate ra http_request... blah blah là thua rồi nhé |
|
Cánh chym không mỏi
lol |
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 07:28:39 (+0700) | #76 | 118294 |
boom_jt
Member
|
0 |
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server |
07/03/2008 07:28:50 (+0700) | #77 | 118295 |
|
ThíchHắcKinh
Member
|
0 |
|
|
Joined: 05/11/2007 21:56:23
Messages: 85
Location: Thiếu Lâm Tự
Offline
|
|
Chị Gammar .. Chị biết thì chị demo cho mọi người đi sao lại bảo người khác demo nhễ |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server |
07/03/2008 07:40:25 (+0700) | #78 | 118299 |
|
vivashadow
Member
|
0 |
|
|
Joined: 08/01/2008 12:36:49
Messages: 95
Offline
|
|
Hic, sôi nổi quá, đọc mờ mắt!
Xin có ý kiến, cái này không ổn.
boom_jt wrote:
2. Dựa trên cách bác conmale đề ra: sử dụng 1 cookie SID không đổi (session) và cookie động (giống như của bác conmale). Chỉ cần cookie động không hợp lệ là SID sẽ bị loại bỏ luôn. Như thế, khi nạn nhân sử dụng cookie "không còn hợp lệ" (do cách khai thác ở trên) để tạo kết nối tiếp theo cũng đồng nghĩa với việc biến cookie "hợp lệ" đang nằm trong tay kẻ tấn công thành bất hợp lệ. Nạn nhân sẽ phải đăng nhập lại để có cookie hợp lệ.
Từ 1 user vô tội, khả năng gởi 1 request mang cookie cũ là có thể, nên sẽ xảy ra tình trạng mất session bất kể có XSS hay mất cắp coookie hay không.
@boom_jt:
boom_jt wrote:
Tuy nhiên, với cách 2 như vừa nêu, giả sử lỗi XSS nằm ngay tại index của diễn đàn (hay trong danh sách thành viên online chẳng hạn), sẽ dẫn đến 1 vấn đề là toàn bộ thành viên sẽ ko thể vào đc diễn đàn, vì cookie của họ liên tục trở thành bất hợp lệ!
Mình chưa hiểu rõ vì sao "cookie của họ liên tục trở thành bất hợp lệ!"
gamma95 wrote:
@vivashadow:
Attacker dễ dàng inject cái script này để disable nguyên đoạn mã html phía dưới, trong đó có cả cái iframe chứa ping.jsp của HVA
<script>window.open() .....</script><!--
Làm vậy thì bứt dây động rừng quá, cấu trúc trang web sẽ bị vỡ và mất nội dung.
Hoặc sẽ chống bằng 1 dòng <!---->
|
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server |
07/03/2008 07:52:48 (+0700) | #79 | 118303 |
|
gamma95
Researcher
|
Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline
|
|
@vivashadow: tui demo vậy thôi, thực tế thằng hacker nó chèn một đoạn html bottom y chang đăng sau, cuối thẻ </html> nó mới phang thêm cái <!-- ... Như vầy là ko bị vỡ cấu trúc nhé |
|
Cánh chym không mỏi
lol |
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server |
07/03/2008 08:03:33 (+0700) | #80 | 118305 |
|
vivashadow
Member
|
0 |
|
|
Joined: 08/01/2008 12:36:49
Messages: 95
Offline
|
|
@gammar95: ừ không vỡ. Nhưng nếu xài <!----> hoặc chuối hơn là để đoạn iframe lên đầu trang cũng dc mà |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server |
07/03/2008 09:48:28 (+0700) | #81 | 118320 |
mrro
Administrator
|
Joined: 27/12/2001 05:07:00
Messages: 745
Offline
|
|
"Con gián" của gamma hại nhỉ?
Anyway, tôi cho rằng, mọi hành động điều chỉnh cookie, như cách anh conmale đề cập, chỉ là những "mánh mung", hòng gây thêm khó khăn cho kẻ tấn công, chứ không phải là một giải pháp triệt để.
Hơi off-topic, tôi nghĩ có lẽ chúng ta đang xác định sai vấn đề cần giải quyết, nên các giải pháp đưa ra đều khó lòng mà triệt để. Vấn đề mà chúng ta cần giải quyết ở đây không phải là xác thực người dùng (user authentication, như mọi người vẫn đang cố gắng triển khai, thông qua các hình thức cookie, username, password, token...), mà phải là xác thực từng hành động mà người dùng thực thi trên hệ thống (transaction authentication).
Tôi đưa ra một ví dụ về sự thất bại của chiến thuật xác thuật người dùng. Ngay ở HVAOnline, trước đây, JForum bị dính một lỗi CSRF (có một topic về đề tài này trên HVAOnline), anh conmale mới triển khai một kiểu securityHash, là một hidden field trong mấy cái form trên HVAOnline. securityHash giải quyết được CSRF cho đến khi gamma, với sự cố "con gián" :-d, đã chôm được luôn cookie (và thật ra khi đã bị XSS rồi, thì securityHash kô còn có tác dụng nữa) và từ đó chiếm luôn session của những người nào mải mê "bắt gián".
Rõ ràng, các phương thức xác thực như cookie, session hay securityHash không phải là giải phát triệt để để bảo đảm an ninh cho phía server, ngăn ngừa những tổn hại có thể xảy ra với server trong trường hợp credential của user bị đánh cắp. Đó là tôi chưa kể đến những vấn đề như MITM trojan có khả năng chôm credential của user một cách tự động và "trong suốt" luôn. Tóm lại, từ máy tính của người dùng đến server, có quá nhiều cạm bẫy và rủi ro có thể khiến người dùng bị chôm mất credential của mình.
Do đó, tôi nghĩ bây giờ phải assump là, người dùng sẽ bị chôm credential, trong trường hợp này là attacker có thể tạo ra một request hoàn toàn bình thường như người dùng. Câu hỏi là có cách nào kiểm tra request đó ở phía server hay không?
Có nhiều cách, tùy theo từng hoàn cảnh, chẳng hạn như:
- đối với các hệ thống tài chính, ngân hàng, họ đều triển khai một hệ thống gọi là "fraud detection system", tạm dịch là hệ thống phát hiện gian lận. Hệ thống này được xây dựng dựa trên nền tảng của AI, có khả năng tìm hiểu, phân tích, học và adapt theo thói quen của người dùng.
Ví dụ như họ phân tích thói quen tiêu tiền của tôi là lần nào cũng rút tiền từ ATM ra cao lắm là 2 triệu, tại một trong 2 máy ATM gần chỗ làm. Nếu một ngày nào đó, tự nhiên ai đó rút ra hết tiền của tôi, tại một máy ATM ở...Lạng Sơn chẳng hạn, hệ thống sẽ báo động và ngừng giao dịch đó lại.
Đươ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")
+ ...
Sorry mọi người, hơi bị off-topic .
-m
|
|
http://tinsang.net
TetCon 2013 http://tetcon.org
Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html |
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 12:03:49 (+0700) | #82 | 118331 |
safari
Member
|
0 |
|
|
Joined: 31/01/2008 01:19:23
Messages: 33
Location: somewhere
Offline
|
|
Hay lắm Thái.
Thực ra các phương pháp ngăn ngừa hiện tại của HVA là khá strictly; khó có thể thực hiện với 1 website cho người dùng bình thường (in term of usability). |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 12:41:37 (+0700) | #83 | 118339 |
|
Choen
Member
|
0 |
|
|
Joined: 18/06/2007 21:14:24
Messages: 132
Offline
|
|
Em có 1 ý kiến thế này , ko biết có wá chuối ko
Khi client login vào forum và gởi 1 request tới server , server sẽ xác nhận tính chất User Authentication của request đó , sau đó request lại client yêu cầu để biết thông tin chính xác của client về IP hiện tại của client , và quá trình này sẽ lập lại trong suốt phiên duyệt web
Khi có 1 request khác tới , nó sẽ xác nhập thông tin về IP của client , nếu có 1 sự thay đổi IP , server sẽ yêu cầu client đăng nhập lại ? Với cách làm này , dù Attacker có lấy dc HTTP header thì cũng ko làm dc jì vì ko thể thay đổi IP đươc ? Em nghĩ là như thế Nếu wá chuối xin mọi người thứ lỗi ^^ |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 13:23:33 (+0700) | #84 | 118343 |
safari
Member
|
0 |
|
|
Joined: 31/01/2008 01:19:23
Messages: 33
Location: somewhere
Offline
|
|
Choen wrote:
Khi có 1 request khác tới , nó sẽ xác nhập thông tin về IP của client , nếu có 1 sự thay đổi IP , server sẽ yêu cầu client đăng nhập lại ?...
Công ty tui xài out-bound Load-balancer, nên không có gì đảm bảo 2 request khác nhau sẽ có cùng một IP. Chẳng lẽ tui phải login lại hoài luôn à???
Phương pháp mà bạn nói thì tụi register.com cũng dùng, làm mỗi lần trong cty muốn xài website của tụi này là điên luôn |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
07/03/2008 19:45:37 (+0700) | #85 | 118356 |
|
Choen
Member
|
0 |
|
|
Joined: 18/06/2007 21:14:24
Messages: 132
Offline
|
|
Có thể áp dụng với 1 số account đặc biệt , tuy hơi phiền 1 chút nhưng đảm bảo ko bi hijack ^^ |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
08/03/2008 00:10:28 (+0700) | #86 | 118389 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
mrro wrote:
"Con gián" của gamma hại nhỉ?
Anyway, tôi cho rằng, mọi hành động điều chỉnh cookie, như cách anh conmale đề cập, chỉ là những "mánh mung", hòng gây thêm khó khăn cho kẻ tấn công, chứ không phải là một giải pháp triệt để.
Hì hì, mục đích đằng sau là để tìm hiểu những giới hạn của giao thức HTTP hiện nay trong phạm vi session management đó em . Cái này quan trọng và lý thú hơn chỉ dừng lại ở mức "quick fix".
mrro wrote:
Hơi off-topic, tôi nghĩ có lẽ chúng ta đang xác định sai vấn đề cần giải quyết, nên các giải pháp đưa ra đều khó lòng mà triệt để. Vấn đề mà chúng ta cần giải quyết ở đây không phải là xác thực người dùng (user authentication, như mọi người vẫn đang cố gắng triển khai, thông qua các hình thức cookie, username, password, token...), mà phải là xác thực từng hành động mà người dùng thực thi trên hệ thống (transaction authentication).
Điểm này hoàn toàn đúng. Tuy vậy, vấn đề nằm ở chỗ xác định sự cân bằng giữa đòi hỏi bảo mật và tiện dụng của một ứng dụng. Một ứng dụng online banking cần "transaction authentication" là điều cần thiết bởi vì mỗi cú bấm đều critical. Đối với một forum, tính critical không cao đến thế. Nếu đặt tính critical của một forum lên mức đòi hỏi "transaction authentication" thì nó bị mất tính linh động và dễ dùng.
Đứng về mặt technology, mình có thể vận dụng nhiều phương pháp để giải quyết tình trạng hijacking. Cái khó là duy trì được mức transparent và friendly trong quá trình sử dụng.
mrro wrote:
Tôi đưa ra một ví dụ về sự thất bại của chiến thuật xác thuật người dùng. Ngay ở HVAOnline, trước đây, JForum bị dính một lỗi CSRF (có một topic về đề tài này trên HVAOnline), anh conmale mới triển khai một kiểu securityHash, là một hidden field trong mấy cái form trên HVAOnline. securityHash giải quyết được CSRF cho đến khi gamma, với sự cố "con gián" :-d, đã chôm được luôn cookie (và thật ra khi đã bị XSS rồi, thì securityHash kô còn có tác dụng nữa) và từ đó chiếm luôn session của những người nào mải mê "bắt gián".
Rõ ràng, các phương thức xác thực như cookie, session hay securityHash không phải là giải phát triệt để để bảo đảm an ninh cho phía server, ngăn ngừa những tổn hại có thể xảy ra với server trong trường hợp credential của user bị đánh cắp. Đó là tôi chưa kể đến những vấn đề như MITM trojan có khả năng chôm credential của user một cách tự động và "trong suốt" luôn. Tóm lại, từ máy tính của người dùng đến server, có quá nhiều cạm bẫy và rủi ro có thể khiến người dùng bị chôm mất credential của mình.
Ở giới hạn forum và ưu tiên cao nhất là hiệu suất + thân thiện, việc ứng dụng bất cứ phương pháp nào khả thi để giảm thiểu dung hại là việc cần thiết. Điểm em đưa ra đây chính là cốt lõi của vấn đề mà mình nên nắm lấy: hạn chế của giao thức và cơ chế quản lý session xuyên qua HTTP. HTTP được tạo ra nhằm phục vụ stateless request / response. Cho đến khi nó được phổ biến, dựa trên giao thức khá "primitive" thời ấy, các công nghệ ứng dụng mới tìm cách khai thác và mở rộng cái hạn chế "stateless" kia. XSS và CSRF được khám phá và exploit mãi sau này. Bởi thế, cho đến lúc này, dựa trên căn bản primitive HTTP để duy trì một session và bảo đảm tính bảo mật là điều khó thực hiện được (nếu không muốn áp đặt những cơ chế kém thân thiện).
mrro wrote:
Do đó, tôi nghĩ bây giờ phải assump là, người dùng sẽ bị chôm credential, trong trường hợp này là attacker có thể tạo ra một request hoàn toàn bình thường như người dùng. Câu hỏi là có cách nào kiểm tra request đó ở phía server hay không?
Có nhiều cách, tùy theo từng hoàn cảnh, chẳng hạn như:
- đối với các hệ thống tài chính, ngân hàng, họ đều triển khai một hệ thống gọi là "fraud detection system", tạm dịch là hệ thống phát hiện gian lận. Hệ thống này được xây dựng dựa trên nền tảng của AI, có khả năng tìm hiểu, phân tích, học và adapt theo thói quen của người dùng.
Ví dụ như họ phân tích thói quen tiêu tiền của tôi là lần nào cũng rút tiền từ ATM ra cao lắm là 2 triệu, tại một trong 2 máy ATM gần chỗ làm. Nếu một ngày nào đó, tự nhiên ai đó rút ra hết tiền của tôi, tại một máy ATM ở...Lạng Sơn chẳng hạn, hệ thống sẽ báo động và ngừng giao dịch đó lại.
Cái này có thể bị kẹt trong context banking. Ví dụ anh đang ở Sydney, thỉnh thoảng anh dùng thẻ để rút tiền ở vài ATM nào đó tại Sydney. Ngày kia anh đi hội nghị ở Sing, anh cần tiền và bị ngưng giao dịch như thế là chết anh .
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.
mrro wrote:
Sorry mọi người, hơi bị off-topic .
-m
Đâu có. Ý kiến của em rất giá trị và không hề off-topic .
Thân. |
|
What bringing us together is stronger than what pulling us apart. |
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
08/03/2008 12:38:06 (+0700) | #87 | 118500 |
0x111111
Member
|
0 |
|
|
Joined: 07/03/2008 20:40:13
Messages: 2
Offline
|
|
Cho mình hỏi vài điều sau:
1_ Tại sao gọi là "từ phía server" ?
2_ Nếu không dùng Cookies thì không bị lỗi này đúng không ?
3_ Mình đề cử thử cách sau xem có được không ?
Đầu tiên là: kiểm tra Session("str") = Cookies("str") ở ngay đầu trang, nếu đúng sẽ cho duyệt tiếp, ngược lại, chuyển về trang default.asp, trang này sẽ tạo 1 chuỗi random và lưu vào cả session và cookies, đồng thời xác lập lại thông tin mới cho cookies, dựa vào các điều kiện hiện hành.
Các file trong 1 ứng dụng đều include đoạn kiểm tra trên.
Cuối trang, tạo 1 chuỗi random mới và thay thế vào session("str") và cookies("str").
Lý giải của mình như sau: (theo mình nghĩ)
+ Đối với User thật: điều kiện kiểm tra đầu tiên luôn đúng. Hoặc ít nhất, cỡ nào cũng sẽ đúng.
+ Đối với User giả: nếu lấy được cookies (vẫn sẽ là cookies cũ), vì đến cuối trang, nó đã replace lại giá trị của cookies này, và giá trị của cookies luôn bị thay đổi sau mỗi lần kiểm tra.
Viết tới đây tự dưng thấy vô lý, cookies thường dùng để lưu thông tin để đăng nhập tự động vào lần sau. Nếu đem đi kiểm tra với session thì cũng như không, nhưng vẫn để bài viết đó, mong mọi người góp ý thêm.
4_ Nếu có bộ lọc tốt(Chỉ cần lọc đầu vào), thì đã gọi là an toàn chưa? Đừng hỏi lọc thế nào gọi là tốt, chủ yếu là các cú pháp nào dùng để lấy cookies thì lọc hết, lọc luôn cả ( ' + ' ) thành "" để tránh dùng 'coo' + 'kies',... tương tự thế.
________________________________________________________
///
N e W b I e
/// |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
08/03/2008 12:53:35 (+0700) | #88 | 118507 |
prof
Moderator
|
Joined: 23/11/2004 01:08:55
Messages: 205
Offline
|
|
Chào cả nhà,
Mấy hôm nay thấy topic sôi động ghê mà bận quá ko thể tham gia thảo luận được với mọi người. Bây giờ mới có thể vào "góp vui" cùng bà con chút xíu .
conmale wrote:
Hì hì, mục đích đằng sau là để tìm hiểu những giới hạn của giao thức HTTP hiện nay trong phạm vi session management đó em . Cái này quan trọng và lý thú hơn chỉ dừng lại ở mức "quick fix".
Hi hi, anh conmale coi bộ muốn bà con "xới tung" HTTP & its related stuff lên mới đã hay sao đó mà đặt giả thiết bài toán khó nhằn ghê . Thành thực mà nói, do bản chất "vốn có" của HTTP là một stateless protocol nên vô hình chung dẫn tới bài toán Session Management trở nên cầu kỳ, phức tạp. Bất kỳ một Web application nào khi có nhu cầu đụng tới vấn đề authentication thì hầu như phải tự thêm thắt các phương pháp "tự chế" (đối với context trong topic này là các thứ khá quen thuộc như cookies, sessionID, securityHash,...) nhằm mục đích "tha thiết" là: xác thực/định danh người dùng.
conmale wrote:
Điểm này hoàn toàn đúng. Tuy vậy, vấn đề nằm ở chỗ xác định sự cân bằng giữa đòi hỏi bảo mật và tiện dụng của một ứng dụng. Một ứng dụng online banking cần "transaction authentication" là điều cần thiết bởi vì mỗi cú bấm đều critical. Đối với một forum, tính critical không cao đến thế. Nếu đặt tính critical của một forum lên mức đòi hỏi "transaction authentication" thì nó bị mất tính linh động và dễ dùng.
Đứng về mặt technology, mình có thể vận dụng nhiều phương pháp để giải quyết tình trạng hijacking. Cái khó là duy trì được mức transparent và friendly trong quá trình sử dụng.
Um, thiết nghĩ anh conmale có vẻ quá "trăn trở" về vấn đề transparent & friendly trong khuôn khổ forum nên khó có thể đạt được một giải pháp "dĩ hoà vi quý". Vì xét cho cùng, trên một forum, các tác vụ quan trọng nhất, đáng để "lừa" nhất, là các tác vụ điều hợp (của mods) nên việc verify lại mật khẩu là điều nên làm trong trường hợp cần thiết.
Em nghĩ có thể kết hợp thêm yếu tố Timestamp (chẳng hạn, khoảng 30 giây) cho securityHash/token (có tính duy nhất cho 1 session) hiện tại của diễn đàn. Theo đó, phía server sẽ lưu giữ một table các securityHash này và sẽ không chấp nhận một request nào đó nếu giá trị securityHash đã và đang được dùng trước đó. Table này sẽ chỉ lưu các securityHash trong khoảng thời gian của Timestamp sau đó sẽ được giải phóng mà không chiếm tài nguyên.
Trong trường hợp nhận được 2 requests với 2 securityHash giống nhau (bị session hijack), khi đó server-side nên cân nhắc trường hợp reject cả hai request này (vì khi đó không rõ request nào là hợp lệ) hoặc tiến hành verify lại password.
mrro wrote:
Do đó, tôi nghĩ bây giờ phải assump là, người dùng sẽ bị chôm credential, trong trường hợp này là attacker có thể tạo ra một request hoàn toàn bình thường như người dùng. Câu hỏi là có cách nào kiểm tra request đó ở phía server hay không?
Có nhiều cách, tùy theo từng hoàn cảnh, chẳng hạn như:
- đối với các hệ thống tài chính, ngân hàng, họ đều triển khai một hệ thống gọi là "fraud detection system", tạm dịch là hệ thống phát hiện gian lận. Hệ thống này được xây dựng dựa trên nền tảng của AI, có khả năng tìm hiểu, phân tích, học và adapt theo thói quen của người dùng.
Ví dụ như họ phân tích thói quen tiêu tiền của tôi là lần nào cũng rút tiền từ ATM ra cao lắm là 2 triệu, tại một trong 2 máy ATM gần chỗ làm. Nếu một ngày nào đó, tự nhiên ai đó rút ra hết tiền của tôi, tại một máy ATM ở...Lạng Sơn chẳng hạn, hệ thống sẽ báo động và ngừng giao dịch đó lại.
Đúng là bài toán authentication chỉ có thể được giải quyết rốt ráo khi không còn phụ thuộc vào việc authenticate users nữa mà thay vào đó là authenticate nội dung giao dịch. Tuy nhiên, để có giải pháp hoàn thiện dựa trên AI, vấn đề thời gian & nghiên cứu nên được đầu tư một cách nghiêm túc. Lý do, nếu hệ thống không được "training" tốt, không lựa chọn được AI learning algorithms tốt, thì khả năng chịu false positive là không thể tránh khỏi.
Mến. |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía serv |
08/03/2008 13:41:04 (+0700) | #89 | 118520 |
boom_jt
Member
|
0 |
|
|
Joined: 02/08/2007 23:51:10
Messages: 125
Offline
|
|
Qua 1 thời gian trao đổi thì mình thấy thế này: vấn đề là ở chỗ bản chất của HTTP - stateless protocol - và cũng theo như anh conmale có mạnh dạn đề ra việc "cải tổ" giao thức. Vậy nên chăng chèn thêm 1 tầng "đệm" vào dưới tầng Application để biến HTTP thành giao thức có trạng thái?
Việc làm này có hợp lý ko khi mà TCP - tầng ngay dưới đã cung cấp 1 kết nối từ điểm tới điểm - có trạng thái?
Đồng thời, nó có giải quyết đc triệt để session hijacking ko trong trường hợp kẻ tấn công cũng chọc sâu xuống tận tầng đệm đó để khai thác (lập trình socket chẳng hạn) ?
các bạn cho ý kiến nha
p/s: @prof: mình chưa hiểu rõ lắm ý tưởng timestamp của bồ, có thể nói rõ thêm cho mình hiểu chút đc ko, sozy |
|
|
|
|
[Question] Re: [Thảo luận] Ngăn ngừa session hijacking xuyên qua XSS từ phía server |
08/03/2008 15:59:27 (+0700) | #90 | 118531 |
|
vivashadow
Member
|
0 |
|
|
Joined: 08/01/2008 12:36:49
Messages: 95
Offline
|
|
Không phải không muốn cải tổ, HTTP là giao thức quá phổ biến và thiết yếu nên người ta luôn cố cải tiến nó đấy chứ. Nhưng chính vì tính chất đơn giản, nhanh, phổ biến và mục đích cơ bản từ nguyên thủy của nó chỉ là để tra cứu thông tin nên có cố gắng bao nhiêu thì HTTP vẫn là HTTP nếu thay đổi quá như boom_jt thì có lẽ HTTP sẽ thành 1 giao thức khác, hoặc chí ít phải đánh đổi các tính chất cơ bản của giao thức, cho nên trước mắt vẫn phải tự chế thôi.
Một nguyên nhân nữa làm ứng dụng web bảo mật kém nữa là Javascript, bản thân JS mang lại nhiều sức mạnh cho web nhưng cũng gây thêm nhiều khó khăn bảo mật cùng với HTML vốn đã là ngôn ngữ thẻ lỏng lẻo.
Javascript's biggest weakness is that it is not secure - douglas crockford
http://www.slideshare.net/jharwig/javascript-security/
Hơi lạc đề nhưng cũng xin bao quát lại 1 chút là hướng cải thiện bây h (XSS nói chung ) là: phía server thì phải liên tục phát hiện và lấp XSS, phía client thì gia cố bảo mật trình duyệt (như là dùng HttpOnly, trusted domain), nâng cấp js/html.
|
|
|
|
|
|
|
|
Users currently in here |
1 Anonymous
|
|
Powered by JForum - Extended by HVAOnline
hvaonline.net | hvaforum.net | hvazone.net | hvanews.net | vnhacker.org
1999 - 2013 ©
v2012|0504|218|
|
|