|
1, Giới thiệu
Hai phần của bài viết này sẽ
trình bày cho bạn một phân tích về các kỹ thuật bảo mật, rủi ro, các tấn công và
cách phòng chống của hai hệ thống quản lý mật khẩu trình duyệt được sử dụng rộng
rãi, đó là Internet Explore và Firefox. Đối tượng chính trong bài viết này đề
cập đến hai trình duyệt IE 6 và 7, Firefox 1.5 và 2.0 và cụ thể là những nội
dung sau:
-
Kỹ thuật lưu mật khẩu: Ý nghĩa của
việc bảo vệ các username và password trên hệ thống file cục bộ thông qua mã hóa.
-
Các kiểu tấn công: Các phương pháp
phá hoại hay vượt qua được sự bảo vệ.
-
Những sai lầm về bảo mật: Người
dùng sử dụng mật khẩu không có kiến thức về khả năng rủi ro.
-
Khả năng sử dụng: Những đặc tính
nhằm nâng cao hay cản trở khả năng sử dụng của các đặc tính bảo mật.
-
Biện pháp đối phó và khắc phục:
Những hành động cần thiết để người dùng và các tổ chức giảm những rủi ro không
đáng có.
Internet Explorer và Firefox đã cùng nhau chia sẻ khoảng gần
95% thị phần của tất cả các trình duyệt. AutoComplete và Password Manager là các
tính năng để lưu username, password và URL tương của IE (từ phiên bản 4) và
Firefox (từ phiên bản 0.7)
Mỗi trình duyệt có các tính năng riêng để hỗ
trợ người dùng bằng việc nhớ các username và password khác nhau như một sự thẩm
định cho các trang web. Vì vậy, khi vào một URL như http://www.gmail.com, nơi có các trường nhập vào, thì cả
Internet Explorer và Firefox đều sẽ nhắc nhở người dùng xem có muốn lưu username
hay password hay không. Khi người dùng vào lại trang web này thì trình duyệt sẽ
tự động điền vào đầy đủ các trường đó.
Mặc dù những tính năng này giúp
đơn giản hóa đáng kể trách nhiệm của người dùng song chúng cũng đưa ra những vấn
đề cần phải suy xét về bảo mật, điều mà sẽ được nói đến trong những phần dưới
đây.
2, Một trường hợp về bộ quản lý mật
khẩu
Sự cần thiết của các bộ quản lý mật khẩu liên quan
trực tiếp đến khó khăn để có thể nhớ một số lượng lớn username và password cho
các trang web cụ thể. Thực tế, cần phải chú ý là bộ quản lý mật khẩu có thể tăng
cường toàn bộ tính bảo mật vì chúng có quyền cho phép mức entropy lớn hơn trong
việc sử dụng các bộ nhận dạng và mật khẩu. Vì vậy người dùng có thể tạo nhiều
username khác nhau thay vì một username để cho những kẻ tấn công khó khăn hơn
trong việc phỏng đoán.
Xét theo khía cạnh cân bằng mà nói thì người dùng
phải tin tưởng vào ứng dụng để thực hiện vai trò của nó (như việc lưu, xử lý một
cách an toàn và những khả năng tiến bộ để cho phép tồn tại của nó). Việc quản lý
mật khẩu không phải là một phương thuốc chữa bách bệnh song chúng cũng có tác
dụng thúc đẩy về mặt công nghệ, tăng khả năng rào chắn đối với những tấn công
bằng cách cải thiện giao diện người dùng để tính toán các môi trường thông
thường vẫn cần đến sự thẩm định.
Người dùng cũng như các doanh nghiệp
cần phải được bảo đảm rằng các hệ thống quản lý mật khẩu phải được sử dụng và
thực hiện đúng quy cách, kiến thức về khả năng rủi ro liên quan. Bài viết này có
thể được sử dụng như một kiến thức cơ bản cho việc thiết kế các bộ quản lý mật
khẩu an toàn hơn bằng việc ôn lại những tấn công, từ đó xây dựng một giải pháp
vững chắc đối phó với các tấn công tương lai.
3, Công việc đầu tiên
Sử dụng cùng một
username và password trong nhiều trang web sẽ làm tăng khả năng thỏa hiệp, chính
nhờ đó mà kẻ tấn công chỉ cần khám phá một username và một password để thỏa hiệp
với tất cả tài nguyên của người dùng. Sử dụng nhiều password, các kỹ thuật ghi
nhớ và mối nguy hiểm khi dùng lại password đều được nghiên cứu một cách rộng
rãi. Thêm vào đó, mở rộng ra Firefox cũng đã được nghiên cứu để giảm khả năng có
thể phỏng đoán password.
4, Các kỹ thuật lưu
password
Các vị trí và kỹ thuật lưu username và password
được đưa ra dưới đây. Thông tin này được sử dụng như một nghiên cứu các kiểu tấn
công cơ bản được sử dụng trong phần 5.
4.1,
Vị trí lưu
4.1.1, Internet Explorer 6 &
7
Trên Internet Explorer (từ phiên bản 4 đến 6) thông tin định
dạng web AutoComplete được lưu trong Registry ở các vị trí dưới đây:
Các
username và password đã được mã hóa:
HKEY_CURRENT_USERSoftwareMicrosoftInternet
ExplorerIntelliFormsSPW
Các địa chỉ Web:
HKEY_LOCAL_MACHINESoftwareMicrosoftProtected Storage System
Provider
Các key mã hóa đối xứng:
HKEY_CURRENT_USERSoftwareMicrosoft Protected Storage System
Provider
Data
Trong Internet Explorer 7, thông tin AutoComplete cũng được lưu
trong Registry nhưng trong vị trí khác.
Các username và password đã được
mã hóa:
HKEY_CURRENT_USERSoftwareMicrosoftInternet
ExplorerIntelliFormsStorage2
Các mục trong registry chỉ được tạo khi người dùng thực hiện
lưu thông tin đăng nhập (username và password) cho một trang web. SPW là viết
tắt của SavedPassWords.
4.1.2, Firefox 1.5 and
2.0
Trong Firefox, các URL (Uniform Resource Locators), các
username và password được lưu trong một file signons.txt:
Các
username và password được mã hóa trong hệ thống Windows được lưu trong:
%userprofile%Application
DataMozillaFirefox Profilesxxxxxxxx.defaultsignons.txt
Khi %userprofile%, là biến môi trường trong Windows, thể hiện
đường dẫn đến thư mục chủ của người dùng.
Các username và password được
mã hóa trong hệ thống Linux đang chạy Firefox được lưu ở vị trí sau:
~/.mozilla/firefox/
xxxxxxxx.default/signons.txt
Vị trí của xxxxxxxx được chọn ngẫu nhiên khi Firefox
được cài đặt. File signons.txt được tạo ra khi bất kỳ login cho một
trang web được lưu. Các login theo sau với các URL được chèn vào trong file. Nó
hoàn toàn không liên quan đến bộ quản lý password nếu trang đó truy cập sử dụng
HTTP hay HTTPs. Các URL không được mã hóa bởi vì chúng được sử dụng như một tham
chiếu (tra cứu) cho việc khớp các login. Đặc biệt hơn, khi một bộ quản lý
password trình duyệt cần điền tự động login cho một trang cụ thể, có URL của
trang được tham chiếu vơi file signons.txt (nếu URL đó tồn tại) thì
username và password tương ứng được điền vào login của trang web.
4.2, Các kỹ thuật truy cập và lưu
trữ
4.2.1, Internet Explorer 6 & 7
Kiến trúc
lưu: Registry
Định dạng: Nhị phân, và được lưu như
một cặp của các giá trị hex trong một loại dữ liệu REG_BINARY.
Mã
hóa: DES- ba cấp.
Truy cập: Bảo vệ API lưu trữ
(cho Internet Explorer 4-6); API bảo vệ dữ liệu (cho Internet Explorer 7)
Các yêu cầu cho truy cập: Người dùng đăng nhập.
Lưu trữ tạm thời: Các key đối xứng được đánh 0 vào bộ nhớ
sau khi sử dụng.
Internet Explorer 4-6 sử dụng bộ cung cấp hệ thống bảo
vệ lưu trữ (PStore) để lưu và truy cập thông tin người dùng gồm có username và
password, các password nhập vào trên định dạng web trong Internet Explorer.
Pstore như định nghĩa bởi MSDN, là một giao diện lập trình ứng dụng được sử dụng
để lưu thông tin một cách an toàn. Trong một công bố gần đây của Microsoft người
ta đã đưa ra:
"… dịch vụ Protected
Storage, không sớm thì muộn cũng sẽ được quan tâm như một phương pháp bảo đảm
cho lưu trữ các bí mật. Ứng dụng Windows đáng kể nhất vẫn sử dụng P-store là
Microsoft Internet Explorer, lưu thông tin Auto-Complete gồm có tên, mật khẩu
được sử dụng để thẩm định dựa trên các form."
Dữ liệu PStore được mã hóa với DES-ba cấp và được lưu trong một
kiến trúc nhị phân. Dữ liệu không mã hóa không thể truy cập trực tiếp thông qua
registry. Mặc dù vậy, việc truy cập và an ninh dữ liệu cần phải được thắt chặt
với các khả năng đăng nhập Windows của người dùng. Khi người dùng đăng nhập, bất
kỳ một chương trình đang chạy dưới nội dung của người dùng có thể tăng khả năng
truy cập đến dữ liệu PStore không mã hóa bằng việc sử dụng các triệu gọi API
đúng. Mặc dù vậy, các tài khoản người dùng Windows khác không thể truy cập vào
dữ liệu PStore khác.
PStore không phải chỉ được sử dụng riêng trên
Internet Explorer mà nó còn được sử dụng chung cho cả kỹ thuật khác của các sản
phẩm Microsoft như Outlook và MSN Explorer. Các chương trình này cũng dễ bị ảnh
hưởng đến các yếu điểm trong thiết kế bảo mật. Một số chương trình Spyware đã
biết cách phá hoại bảo mật PStore thông qua API có khả năng lập trình dễ dàng
của nó và tăng mức truy cập không chính đáng.
Internet Explorer 7 sử
dụng giao diện lập trình ứng dụng dữ liệu bảo vệ (DPAPI) nhưng những khả năng
trên vẫn có thể tồn tại và được công bố đến các chương trình mở rộng thông qua
các triệu gọi API.
Mật mã cho AutoComplete trong IE7 được thể hiện dưới
đang sử dụng thuật ngữ chuẩn:
EK - Encryption Key (Khóa mã hóa)
RK - Record Key (Khóa bản
ghi)
CRC - Cyclical Redundancy Check (Kiểm tra tình trạng dư thừa theo chu
kỳ)
Hash - Secure Hash Algorithm (SHA) (Thuật toán bảo mật Hash)
Khả năng lưu trữ:
EK: URL
RK: Hash(EncryptionKey)
C: CRC(Record Key)
V: {dữ liệu}EK
Lưu trữ (C, V) được đánh chỉ số
bằng RK trong Registry, làm mất hiệu lực EK
Khả năng phục hồi
lại:
EK: URL
RK: Hash(EK)
Tra cứu RK trong Registry, xem có
khớp tương ứng dữ liệu mã hóa và dữ liệu {V}EK hay không
Vì vậy URL được yêu cầu để phục hồi lại các khả năng (dữ liệu)
như nó xếp vào EncryptionKey (EK).
a, Những quan
tâm về truy cập của Internet Explorer.
IE AutoComplete làm việc dưới giả thuyết rằng một tài khoản người dùng
Windows cụ thể hoàn toàn có thể truy cập hợp lý với cơ sở dữ liệu mật khẩu. Vì
vậy, nếu một người dùng không được phép có sự truy cập hợp lý đến máy tính và
tài khoản được đăng nhập hoặc nó không phải là một password được bảo vệ thì kẻ
tấn công có thể lạm dụng các đặc quyền tài khoản và sử dụng password một cách
bất hợp pháp. Sự truy cập hợp lý có thể được thực hiện trực tiếp trên máy tính
đó hoặc sử dụng máy khách truy cập từ xa (VNC, trạm làm việc từ xa,…).
Như vậy, nếu không có những tôn trọng về việc sử dụng máy (như việc các
phòng được ngăn cách bởi khóa, hay mật khẩu để bảo vệ việc đăng nhập của các
chương trình bảo vệ màn hình) thì bất kỳ ai cũng có thể sử dụng trực tiếp trên
máy tính để truy cập tới bất kỳ website nào cho phép quản lý password. Nếu quản
lý máy tính tốt, thì một người không đáng tin muốn tăng khả năng truy nhập tới
bất cứ thứ gì (từ email cá nhân của một người tới tài khoản ngân hàng) sẽ gặp
khó khăn.
Thêm vào đó, trong các trường hợp nhiều người có cùng một tài
khoản người dùng hợp lý (một thực tế bảo mật kém), các vấn đề tăng vọt với người
dùng bất hợp lý. Các kỹ thuật điều khiển từ xa để tăng truy cập được đưa ra
trong phần sau và cũng có hiệu lực với các bổ sung thêm vào.
4.2.2, Firefox 0.7-1.5 và 2.0
Kiến
trúc lưu: Dạng file văn bản (signons.txt)
Định
dạng: ASCII, bằng sử dụng việc mã hóa Base64 (ngoại trừ URL và các
trường)
URL (ví dụ. www.gmail.com)
Trường tên (trong
cleartext,ví dụ: username, email, userid,…)
Mã hóa Base64 cho các thông tin
ở trên
Trường tên (ví dụ: password, pass,...)
Mã hóa Base64 cho các
thông tin ở trên
... (Có thể có nhiều mục cho mỗi URL)
(Mỗi mục URL
kéo dài trong chu kỳ phân chia dòng)
Mã hóa: DES ba cấp (chế độ CBC)
Truy cập: Các dịch vụ an ninh mạng API (NSS)
Các yêu cầu cho truy cập: Người dùng đã đăng nhập và mật
khẩu chủ (nếu thiết lập)
Các file liên quan: Các chứng chỉ
(ký các Public Key) được lưu trong certN.db, còn các cơ sở dữ liệu Private Key
được lưu trong keyN.db và các Module bảo
mật được lưu trong secmod.db
Chú
ý rằng các vị trí file được định tị từ trước trong phần 4.1.
Firefox sử
dụng Network Security Services API để thực hiện mã hóa. Nó liên quan đến Password Manager Firefox để tạo ra Public Key Cryptography Standard
(PKCS) #11 (định nghĩa API cho các modul bảo mật nhóm thứ ba gồm cả phần mềm và
phần cứng). Sử dụng PKCS#5 để mã hóa password. Firefox cũng có một tùy chọn của
việc sử dụng mođul bảo mật luân phiên cho bộ quản lý password, đó là chuẩn xử lý
thông tin quốc gia (FIPS) 140-1. Master Password được sử dụng cùng
chung với một phần trong file keyN.db thường được sử dụng để cung cấp một Master Key. Master Key sau
đó được sử dụng để giải mã username, password được lưu trong Password
Manager.
Mặc dù không dễ dàng giải quyết nhưng NSS API có một vài
chức năng quan trọng đối với Firefox hay một chương trình liên quan để tăng khả
năng truy nhập vào cơ sở dữ liệu có password. Các thiết lập password được nắm
giữ bởi (PK11_SetPasswordFunc), giải mã
dữ liệu cơ số 64 (NSSBase64_DecodeBuffer), giải mã (PK11SDR_Decrypt) cho phép một chương trình liên quan đến các
username và password liên quan; đây quả thực là một vấn đề đơn giản. mã thực tế
cần khởi chạy NSS, tuyên bố các biến, quản lý bộ đệm,… Mặc dù vậy sự bảo mật của
toàn bộ hệ thống dựa vào sức mạnh mật mã của Master Password (được tạo ra bởi
người dùng) và khả năng truy cập vào file key3.db (bao gồm những phần quan
trọng) được lưu trong profile của người dùng.
Modul bảo mật FIPS 140-1
có thể cho phép bằng việc định hướng theo sự xếp đặt sau:
Firefox 1.5 trên Windows:
Tools | Options |
Advanced | Security Devices | NSS Internal FIPS PKCS #11
Firefox 2.0 trên Windows:
Tools | Options | Advanced |
Encryption | Security Devices | NSS Internal FIPS PKCS #11
5, Các tấn công vào bộ quản lý
password
Phần này sẽ quan sát vài tấn công nhằm phá hoại
các bộ quản lý password. Hai tấn công như đã được thảo luận và sau đó chúng tôi
sẽ gộp thành một phần trong một loạt các bào báo.
Một công nghệ chung
nhất để tìm tất cả các đường thâm nhập một hệ thống là sử dụng một sơ đồ hình
cây. Mục đích của sơ đồ này được thể hiện bên dưới hình 1 là sự thỏa hiệp hoàn
tất của cơ sở dữ liệu password.
Kết quả của việc tăng truy nhập vào cơ sở dữ liệu sẽ cho phép
kẻ tấn công đạt được tất cả các URL, username, password mà đã được sử dụng để
xác nhận trong các trang. Bộ quản lý password thỏa hiệp cho phép kẻ tấn công
truy cập vào bất kỳ thứ gì từ e-mail đến bảo hiểm, ngân hàng hay thậm chí cả
thông tin cộng tác bên trong mạng nội bộ. Một vấn đề nhỏ (không được liệt kê
trong cây trên) sẽ thỏa hiệp với khả năng đăng nhập cho các trang đặc biệt.
Một hệ thống quản lý password được phát triển cho ứng dụng và các thành
phần người dùng. Để thỏa hiệp với cơ sở dữ liệu password hay một đăng nhập đặc
biệt thì chỉ cần tấn công vào thành phần yếu nhất của hệ thống. Trong trường hợp
này, các liên kết yếu nhất luôn là người dùng (không mã hóa hoặc bổ xung thêm
phần mềm). Các tấn công đều dựa vào giao diện giữa người dùng và bộ quản lý
password hoặc giữa bộ quản lý password và trình duyệt.
5.1, Trình duyệt không bị các tấn công JavaScript
Hai tấn công JavaScript sẽ không được thảo luận trong
phần này trước trước khi kết luận: một tấn công chuẩn và một ứng dụng Ajax.
5.1.1, Tấn công JavaScript chuẩn
Giả
định: Kẻ tấn công có tài khoản người dùng hợp lệ
Kết
quả tấn công: Kẻ tấn công có khả năng xuyên qua một trang đã lưu đăng
nhập và 1) Tăng truy nhập 2) Sử dụng JavaScript để phát hiện username và
password.
Thiệt hại khác: sử dụng password bị lộ để
truy cập vào bộ quản lý password hoặc các ứng dụng khác và các trang có cùng
password.
Sử dụng JavaScript hoàn toàn có thể phát hiện ra các password
đã được lưu trên bất kỳ trang nào thông qua DOM. Khi một ai đó viếng thăm một
trang nào đó mà lưu lại username và password thì password luôn luôn được để ẩn
bằng các dấu *. Đó là những gì mà người dùng nhìn thấy; nhưng trình duyệt thì
lại lưu password bằng mã ASCII thực và đệ trình nó khi hành động đệ
trình được cần đến. Việc sử dụng các dấu * hoàn toàn tốt trong thiết kế để ngăn
chặn ngoài giao diện.
Để làm việc xung quanh phạm vi ngăn ngừa này, một
kẻ tấn công thông minh có thể sử dụng cả JavaScript được nhúng trong trang HTML
hay chạy một script sau khi tải trang, chúng ta cho rằng kẻ tấn công đã xác định
được username và password.
Mã JavaScript hoàn toàn dễ dàng có thể truy cập online. Nó có
thể được nhúng trong HTML hoặc được chạy trong một bookmarklet. Một bookmarklet
là một chương trình JavaScript nhỏ được lưu như một URL và chạy cục bộ trong
trang web sau khi tải.
Sử dụng logic lập trình, một kẻ tấn công có thể
lặp đi lặp lại thông qua tất cả password-based elements (như trong hình 2) của
DOM; các giá trị tương ứng với các đối tượng password này sẽ được lấy lại sau
đó, việc phá các dấu * là không thể. Bất kỳ ai hay một chương trình nào logic
với máy khách Web (Internet Explorer hoặc Firefox) có thể “click” trên một link
và tìm ra được password.
javascript:(
function(){
var s,F,j,f,i;
s =
"";
F = document.forms;
for(j=0; j f =
F[j];
for (i=0; i if (f[i].type.toLowerCase() ==
"password")
s += f[i].value +
"n";
}
}
if (s) alert("Passwords in forms :nn"
+ s);
else alert("No passwords in forms on this
page.");})();
| |
Hình 1: Mã JavaScript để lấy lại
password. |
5.1.2, Việc lấy password bằng Ajax
Giả thiết: Kẻ tấn công truy cập đến một web proxy trong
suốt hay được cấu hình cho web máy khách.
Kết quả tấn
công: Kẻ tấn công có khả năng chèn, xóa hay thay đổi nội dung trang,
JavaScript cho phép lấy được username và password trên bất kỳ trang nào có các
kết nối HTTP (thậm trí nếu SSL submit được sử dụng tại thời điểm sau đó).
Thiệt hại khác: Cho phép sử dụng cùng một đăng nhập để
truy cập vào hệ thống máy tính, các ứng dụng khác và các trang sử dụng cùng
username và password.
Trong vấn đề được trình bày trong hình 4 dưới đây,
chúng ta có một người dùng đang mở một trình duyệt web và muốn truy cập vào
thông tin ngân hàng của anh ấy trên một máy chủ từ xa. Máy khách yêu cầu trang
web chính của nhà cung cấp (như American Express). Mặc dù vậy, những thông tin
trong câu trả lời đã bị thay đổi thông qua một proxy server. Các proxy server
thường được đặt để bảo vệ nhận dạng các địa chỉ IP, lọc; chúng thực hiện như một
trung gian truyền thông giữa máy khách và máy chủ.
Hình 2: Việc lấy password bằng Ajax
Khi kẻ tấn công kiểm soát được proxy thì chúng có thể nhúng
JavaScript để lấy và gửi username và password thông qua một yêu cầu đồng bộ đến
máy chủ (XMLHttpRequest). Username và password có thể đạt được thông qua
JavaScript (bộ quản lý password tự động điền vào đăng nhập) hay thông qua kỹ
thuật định thời để đợi tới một thời điểm hợp lý (ví dụ 5 giây) cho phép người
dùng nhập vào thông tin và sau đó JavaScript chạy và gửi các dữ liệu đăng nhập
cho kẻ tấn công. Hình 4 đã thể hiện trình duyệt đang yêu cầu một file XML gồm có
các thông tin đăng nhập (bobpassword). Máy chủ sẽ bỏ qua yêu cầu bởi vì nó không
hợp lệ nhưng kẻ tấn công lại tăng mức đăng nhập tại điểm này.
Việc phân
định ra các quá trình là rất quan trọng, quá trình này sẽ thẩm định người dùng
đến máy chủ và phân chia mã độc hại có thể gửi username và password đến kẻ tấn
công. Trên một trang nào đó, các thông tin đăng nhập được nhập vào trước khi kết
nối SSL được thành lập. Điều này là điểm chính của tấn công, nếu có một kết nối
SSL được thiết lập trước việc đăng nhập dữ liệu thì proxy server không thể thấy
được lưu lượng được mã hóa. Tuy nhiên một vài trang sử dụng SSL submit (như
Yahoo, AMEX,…) hình thành nên các kết nối thẩm định mã hóa sau trang gốc được
tải thì chúng sẽ có các lỗ hổng với các loại tấn công về vấn đề này.
Bạn
sẽ nhận thấy rất nhiều điều quan trọng khi so sánh sự khác nhau trong các đặc
tính quản lý password của hai trình duyệt lớn:
|
Đặc tính |
Internet Explorer
7 |
Firefox
2.0 | | Lưu username, password và
URL |
yes |
yes | | Password truy cập thông qua JavaScript |
yes |
yes | | Password truy cập thông qua phần mềm
truy cập |
yes |
yes | | Bảo vệ password (không chói buộc tài
khoản người dùng) |
|
yes | | Password Prompt khi bắt đầu session để
lưu các password |
|
yes | | Dễ dàng xuất dữ liệu
username/password |
|
yes | | Mã hóa |
yes |
yes | | Giải mã |
|
yes | | Password Manager chọn "Show
Passwords" |
|
yes |
Với vài mục cuối trong bảng trên, chú ý rằng cần thiết phải chú
ý đến các vấn đề tranh luận dù đó là một đặc trưng tin tưởng hay một lỗ hổng bảo
mật, mặc dù vậy, thỉng thoảng cũng không có phương pháp nào cho việc lấy lại
password khi bị quên.
Kết luận của phần 1
Phần 1 của bài viết này đưa ra một công việc nền tảng
cho việc định địa chỉ các vấn đề liên quan đến quản lý password, nhưng thực tế
được định địa chỉ hai điểm đầu tiên đưa ra tại phần đầu của bài viết, nó đã giải
thích kỹ thuật lưu password của cả Internet Explorer và Firefox, và sau đó đã
trình bày hai tấn công JavaScript có thể sử dụng để phá hoại các trình duyệt.
Theo Quản Trị Mạng
Advertisements:
Nội dung mới hơn
Nội dung khác |
