Analysis of Web application client Trojan Horse war scenario (1)

Bkjia.com exclusive Article] Today, let's talk about the Client Security story of Web applications. This story describes how attackers can launch attacks from the Web application client. This is a very simple but chilling tactic: The reason it is chilling is that attackers can give other users the chance to show their souls and let them do something they don't want to do; the reason for simplicity is that attackers only need to send an email to users or try to get them to a web page to achieve the above purpose. Sometimes, this security issue is called "client Trojan attack"-it may be inspired by the story of the ancient Trojan attack. However, it doesn't matter if you are not familiar with this distant story. This article will explain the problem to readers in detail and discuss possible solutions.

I. Web application client Trojan attack

The best way to introduce this security problem is to analyze instances. According to the principle of gradual progress, we will first introduce a simple example, and then discuss more complex examples, such as network banking. Yes, network banking also faces such threats ). We first look at a hypothetical voting site that allows users to vote for different candidates and calculates the election results. The web page used for voting may contain the following HTML code:

<form action="http://www.example.com/vote.asp" method="get"> <input type="radio" name="alt" value="1"/>Alternative 1<br/> <input type="radio" name="alt" value="2"/>Alternative 2<br/> …… </form>

Because the form uses the GET method, the user will submit the form through a URL similar to the following when voting for his desired candidate:

http://www.example.com/vote.asp?alt=2

Now, attackers will try to trick other users into clicking these links, such as copying the above URLs and sending them in a large number via email, and claiming to the recipient that these URLs are linked to a thing that can be tempted, such as very interesting games, naked girls, sensational reports, funny jokes, and so on. In fact, we have almost no way to prevent them from doing this-you guys, who have not received any spam ?! If some people click these links, they will vote for the candidate that attackers like. In this way, the statistical results will be tricky.

You may disagree with this example. First, you may say that most users do not click such a link because it looks suspicious. However, this is not a problem for attackers, because they can use redirection technology to hide URLs and confuse more users. In an email, he can direct a website to another page instead of a voting site. For example, he can use a URL pointing to his own server:

http://www.badguy.com/nicejoke.html

You may think this is a joke page when you see "nicejoke" in the link. In contrast to what you think, this nicejoke.html page does not contain any jokes, but contains the following HTML code:

<meta http-equiv="refresh" content="0, url=http://www.example.com/vote.asp?alt=2">

Once the browser reads the meta tag, it will be redirected to the URL of the voting page. It is too long for the user to understand what is going on! Of course, attackers can achieve the same effect by using scripts or HTTP Location headers.

The second reason you have doubts about this example may be: in this example, using a GET request is incorrect. According to the RFC 2616 document of HTTP, POST requests should be used when actions have side effects, such as security risks. After POST is used, the voting details cannot be put in a URL, because the parameters in the POST request are hidden in the request itself. However, this does not prevent attackers from following the steps-they can not trick the browser into accessing the above URL, but cheat the victim to browse an automatically submitted form, such as the following form:

<form name="f" action="http://www.example.com/vote.asp" method="post"> <input type="hidden" name="alt" value="2"/> </form> <script>document.f.submit()</script>

The form named "f" contains a hidden field in which the parameter "alt" has been set by attackers to their selected values. The JavaScript code is under the form, and its function is actually to submit the form, as if the user presses a button that does not exist.

The bad guys can insert the code into a web page and trick users into accessing it. As a result, when the victim understands, they have already voted for others.

A better way is to embed the preceding form into an HTML-encoded email. Some popular email clients can not only view HTML emails, but even execute JavaScript code. Unfortunately, users may not even need to read emails because they have read the attacker's emails and unknowingly voted for them. If the email program automatically previews the emails, they do not even need to read the emails.

Note that Microsoft Outlook uses the IE browser components to display HTML-format emails. In a test on Windows 2000, the author found that the IE instance used by Outlook will share everything with the opened IE, including session cookies. Therefore, you must remember this point, especially when it comes to the network banking in the following article, because it paves the way for cooler Remote Control email. Fortunately, Windows XP does not run scripts embedded in an HTML-format email by default-at least the scripts I tested are not executed.

So far, we have examined a simple application for voting. However, the chilling client Trojan war also involves identity authentication. Because these Trojan Horse attacks operate by deceiving a user or accessing the target site through his browser, only when the user has logged on to the target site, A Trojan horse can do various things in the name of this user.
Assume that a user has logged on to his network bank, and an attacker wants to impersonate the user to make a fortune, as long as he can cheat the user to browse the following content:

<form name="f" action="https://bank.example.com/pay.asp" method="post"> <input type="hidden" name="from-account" value="1234.56.78901"/> <input type="hidden" name="to-account" value="9876.54.32109"/> <input type="hidden" name="amount" value="10000.00"/> </form> <script>document.f.submit()</script>

Now, if the victim has already logged on to the bank and the bank accepts such forms, the user will transfer the money to the attacker's account without knowing it, of course, attackers can exploit this privilege to trick others.

To achieve this, the victim must have logged on to the target site, or the attacker will be helpless. However, if you select the "Remember password" option, it will remain in the logon status. This is also true if the target site is an Intranet Based on domain authentication, such as NTLM on Microsoft IIS. Fortunately, "serious" websites such as banks do not provide automatic Authentication-attackers may think this is "unfortunate ".

If the user is not always logged on, the attacker must first attempt to log on to the target site in some way before deceiving the user to browse malicious HTML. For websites that allow users to add content, such as forums, this may be easy: simply add a very attractive declaration to invite people to view a link. However, in many cases, attackers cannot insert messages to the target site. In this case, they have to think differently. At this time, social engineering may be useful! For example, our target website is a bank named bank.example.com. attackers want to allow the user to log on to the bank first and then trick the user into browsing the above transfer form.

Therefore, attackers can send an email that appears to be from the bank to the victim, for example:

To: Victims From: security@bank.example.com Subject: Urgent Notice. Please read it now! Dear customer! According to the report of the intrusion detection system, we suspect that your account has been maliciously attacked, Therefore, please help us to investigate your account. Please log on to your account immediately after receiving this notification, After logging on, click the following link: Http://bank.example.com @ 167772161/check.html After that, follow the prompts. We apologize for the inconvenience! And wish you success! XX Bank Emergency Response Team

Most users think that the URL points to the Web server of the bank, but this is not the case. After the @ symbol is used, the URL actually uses the command browser's username bank.example.com to connect to site 167772161. A transfer is a page containing HTML code that automatically submits a transfer request. Once the victim is hooked up, the attacker will make a fortune.

For some banks, one transfer takes two steps. First, you must provide all transfer details: The transferout account and the transferin account, amount, payment date, and so on. All such information is temporarily stored in the user's session. After the information is collected, the Bank also requires the user to accept the transaction details. Do not consider these banks as more secure than automated banks in the face of client Trojans. These sites may be as easy to be cheated as step-by-step sites: follow the implementation method of the validation steps to allow victims to browse sites that contain multiple frame frames. Each frame corresponds to one step, as follows:

<frameset rows="50%,50%"> <frame src="http://www.badguy.com/info.html"/> <frame src="http://www.badguy.com/confirm.html"/> </frameset>

After the renewal, it will arrive at the server. As for others, I don't think it is necessary to say more.

No matter what method the attacker chooses, as long as the victim sees the page caused by the transfer, it will cause his suspicion. The solution to this problem is to embed the page into a frame that is not noticed, and put some forged information in another frame. If HTML output is not filtered in some places of the target site, another method is to redirect the browser to another page through a Cross-Site Script once the transfer is completed.