New ways to play web security [6] preventing repeated use of graphic verification codes

When completing key business operations , Requiring the user to input a graphic captcha is a way to prevent automatic attacks . To be on the safe side , Even for the same user , You should also update the captcha when you re-enter information .iFlow Business security reinforcement platform We can strengthen the treatment in this respect .

---

A website system requires users to input the graphic verification code when logging in . If the account information is wrong and the system prompts , When the user re enters the account information , The original captcha can still be used . Let's see how to use iFlow So that the captcha is updated every time .

One 、 Original website

1.1 Normal user access

The user entered the correct captcha character when logging in , If the submitted account information is wrong , The system prompts login error .

chart 1

The user still uses the original captcha character , After submitting the correct account information , The system prompts that the login is successful .

chart 2

HTTP The interaction process is as follows ：

surface 1

1.2 The attacker visited

User login failed , The website didn't update the captcha , But still accept the captcha for a period of time . This feature is user friendly , But it increases the security risk .

such , Even if the attacker does not use the graphical captcha recognition tool , You can also manually identify the verification code , Within the expiration time of the captcha , Use the tool to make multiple hit requests , And record the password combination of the successful login account .

chart 3

HTTP The interaction process is as follows ：

surface 2

Two 、iFlow Virtual patched website

We are Web Pre server deployment iFlow Business security reinforcement platform , It has the ability to intercept 、 Calculate and modify both ways HTTP Message and storage capacity , Become Web Virtual patches applied . In this case ,iFlow Record all the captcha , Users are not allowed to reuse these captcha .

2.1 Normal user access

iFlow Duplicate captcha is not allowed . After normal user login failure , Need to refresh the page or refresh the verification code before logging in . If the user uses the same captcha ,iFlow Will automatically refresh the page and generate a new captcha , The user needs to enter a new verification code to log in .

Normal users HTTP The interaction process is as follows ：

surface 3

2.2 The attacker visited

As shown before , After the attacker identifies the captcha manually for the first time , Use attack tools to send different accounts with the same verification code continuously / Password combination to try to login .iFlow Block these requests , It is found that the captcha has been used , Then return to 302 Redirect response . The identification process is not Web On the server , The attacker can't get the identification result .

Of the attacker HTTP The protocol interaction process is as follows ：

surface 4

2.3 Code

iFlow Built in W2 A language is a language designed to implement Web Apply security hardened class programming language . It's somewhere between configuration and common language , Have the basic elements of programming and aim at HTTP A unique extension of the protocol , Be able to write logic involving complex judgment and dynamic modification for business system .

Considering that users of security products are usually non programmers , They are used to facing configuration files rather than a piece of code . therefore ,W2 Language contains language elements , Still presented as a rule file , And it can reflect the hierarchical structure and facilitate lexical verification JSON Format .

use W2 Language to achieve the above virtual patch code is as follows ：

{
    "if": [
        "streq(REQUEST_FILENAME, '/shopx/index.php')",
        "streq(@ARGS.s, '/index/user/login.html')"
    ],
    "then": {
        "if": "contain(SESSION.used_vcode, @ARGS.verify)",
        "then": {
            "verdict": {
                "action": "redirect",
                "param": "/shopx/index.php?s=/index/user/logininfo.html",
                "log": "user ${SESSION.user} reuse verify code."
            }
        },
        "else": "[email protected] = SESSION.used_vcode .. ',' .. @ARGS.verify"
    }
}

The sample code has only one rule , It uses stored variables used_vcode Record all used captcha . When there is a login request , The rules determine the request parameters of the captcha verify Are you in this session (SESSION) Storage variables for used_vcode in ：

1) If there is ： Indicates that the request reuses the captcha , Directly return the response to the login page .

2) If it doesn't exist ： Indicates that the request uses a new captcha , Add CAPTCHA to this session (SESSION) Storage variables for used_vcode in , Continue with the actual login authentication process .

Be careful ： In the above conversation used_vcode It's stored on the server side iFlow In storage , The attacker can't see the data in the browser, let alone modify it .

3、 ... and 、 summary

iFlow With one rule, you can , Avoid users using duplicate captcha .

It should be noted that , The solution in this article is just an example , It affects the fluency of human-computer interaction to a certain extent . and iFlow Is a flexible class programming language , Using it should be able to write a more complete process .（ Zhang Ge | Tiancun information ）