Skip to content

Latest commit

 

History

167 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

NGX HTTP JS Challenge Module

This is a fork of https://github.com/simon987/ngx_http_js_challenge_module

It's a pretty straightforward proof-of-work challenge for NGINX. The way it works is as follows:

  • The client makes a request to the server.
  • The server hashes the client's address, the time (clamped to a configurable interval) and a secret string all together to create a "challenge" (SHA-1 hash, represented in hexadecimal as a string).
  • The client has to generate a new string prefixed by the "challenge" string and whose SHA-1 hash contains 0xB00B at the byte offset given by the first digit (nibble) in the challenge string.
  • The client sends its response to the challenge as a cookie.

New Features in this Fork

Bypass Tokens

Certain pages can be marked as "bypass" pages. Visiting these pages sends the client a cookie which lets them skip the challenge elsewhere. This is configurable and can be turned on/off per-location. The rationale here is that scraper bots do not access your site normally and there are often pages which are frequently visited by legitimate users but completely ignored by scrapers. Therefore if you enable the bypass setting on a page that is ignored by the traffic you want to restrict, you can avoid serving the challenge to legitimate users of your site.

"Grace Period"

The challenge generation works by hashing the timestamp of your request. To control how long a given response will be valid, this timestamp is clamped to a configurable interval. For example: if the interval is one hour, the timestamp 07:45 will be converted to 07:00 before being hashed. The problem with this is that ideally after completing the challenge the client would have one hour before they have to complete the challenge again. However, if the client completes the challenge at a time very close to the end of the hour, they will not have very much time before they have to complete the challenge again! If the client completes the challenge at 07:52, they only have 8 minutes before their response will be invalid and they have to complete another challenge.

My solution is to make it so that if the client fails a challenge, their response is also checked against the previous time interval and considered a success if it passes there. This still has the problem that the amount of time for which a response to the challenge is valid can vary, but it guarantees that passing the challenge will allow you to access the site for at least the configured time interval, with the possibility of granting access for longer.

About

Proof-of-work challenge to protect nginx from abusive scrapers

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages