The graphic captcha is bypassed by session replay, do we need to add another layer of form anti-spam?
The captcha module announcement says that submitted forms can be replayed and bypassed, should we add an additional layer of form anti-spam? Yes, but the additional layer is not to add another graphical captcha, but to supplement 'one-time' and 'cost' these two things. The angle of the Drupal announcement is that the module did not completely invalidate the verified session that has been released, which means that the same verification result can be used again; this kind of problem is not due to insufficient recognition rate, but because the verification status was not cleared in time.
Which part is bypassed by replaying?
In the normal link, the user solves the captcha first, and the server records that 'this session has passed'. Then, when submitting the form, the state is directly referred to. The bypass occurs in the step of referring: the state has not been consumed in one go, and by carrying the same passed state repeatedly, it is possible to resubmit without solving a new question.
| Link | function | Whether it is reused when replayed |
|---|---|---|
| Question and answer | Determine if the requestor is a person | Skipped |
| Record the passing state | Remember that this one has passed | Repeatedly used |
| Form submission verification | Check fields and frequency | Need to intercept by yourself |
| Storage and audit | Decide whether the content is public | Rubbish has entered |
The state that can pass through this link is a key node. A usable judgment method is to manually replay the same request after the submission is successful, and observe whether the server requires re-verification. If it is still accepted, it means that the scope of the state's role is too large.
Failure surface when only one layer of verification is in effect
The failure surface of single-layer verification is not only in replay. Script submission bypasses front-end rendering, and if graphical verification is made purely front-end validation, it is equivalent to no validation; third-party verification services are affected by network and quota, and the release strategy at timeout needs to be clear, default release will let the service exception become a window for garbage influx.
Another type is low-cost automation: manual captcha services turn the verification process into a repetitive action with minimal cost, at this time, interception depends on submission frequency, field consistency and content quality, not the verification itself.
What do honeytrap fields and verification services each block?
The honey pot field is an input item placed in a form that is invisible to humans but can be filled by scripts. Once it has a value, it is identified as a robot. It has almost zero cost and does not affect the real human experience, and it can block a large number of simple scripts that do not look at the style; what it cannot block is the submitter that specifically identifies and skips hidden fields.
The validation service (such as form access to reCAPTCHA and other human verification) is responsible for another segment: judging the behavior characteristics of the requestor and cooperating with submission frequency restrictions to set a limit on repeated submissions from the same source within a short period of time. The combined division is that the honeypot is responsible for filtering out a large number of inexpensive scripts, and validation and frequency control are responsible for increasing the cost of the remaining requests, and the server then changes the verified status to one-time consumption.
How to accept the interception effect after going online
Acceptance should be done from the submission end, not just by looking at the configuration items. It is recommended to leave three sets of comparisons: a real person submitting once in a normal browser, a submission with hidden fields filled, and repeated submissions from the same source within a short time. All three should leave results in the background messages or garbage records, so that you can see at which layer the interception occurs.
The content side still needs a backup. AnQiCMS can integrate the reCAPTCHA verification code as a verification item, so that comments can enter the background list for review one by one; sensitive word filtering and keyword replacement in the content security settings are responsible for intercepting obviously illegal text before and after storage, and parts that require manual judgment go through content review to avoid completely relying on the verification link. Separate the three levels of results to determine which level needs to be supplemented.
Common questions
Do you need to add another layer after upgrading the verification module?The upgrade solves this cause that the status has not been canceled. The role of honeypot and frequency control is to provide judgments independent of the verification results outside of verification, to avoid the problem of a single point occurring again.
Will adding the honeypot field hurt real people?The honeypot only rejects requests that fill in hidden fields. Real people's normal operations will not trigger it. It is important to note that auxiliary technologies and automatic filling tools may fill in values, and when there is a false rejection, first check whether the field has been automatically filled.
Should the verification service timeout be allowed to pass or intercepted?Both should have a clear strategy. For forms that can be retried, such as comments and registration, prompting to retry later after a timeout is more stable than the default; the default will turn service exceptions into a window for garbage to flood in.