Download the PHP package phpgt/csrf without Composer
On this page you can find all versions of the php package phpgt/csrf. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Package csrf
Short Description Automatic protection from Cross-Site Request Forgery.
License MIT
Informations about the package csrf
Automatic protection from Cross-Site Request Forgery.
This library handles CSRF protection automatically for you, including generating tokens, injecting them into all forms in the page and then verifying that a valid token is present whenever a POST request is received.
Usage: Protection in Three Steps
The CSRF library does two things:
- Injects CSRF tokens into
form
s - Verifies
POST
requests to make sure they contain a valid token
Each is just a single method call, but you need to set up first.
Step 1: Set up
Start by creating the TokenStore. There are currently two implementations — the ArrayTokenStore
and SessionTokenStore
. The ArrayTokenStore
is the most basic and does not persist in any way, but can be extended into custom integrations. The SessionTokenStore
is an inbuilt implementation that persists tokens between requests, so that tokens generated for one page request can be checked on another. The easiest way to add CSRF protection is to use the Session:
Step 2: Verify
Before running any other code (especially things that could affect data), you should check to make sure that there's a valid CSRF token in place if it's needed:
If the request contains a POST and there is no valid CSRF token, a CSRFException
will be thrown — so you should plan to catch it. Remember, if that happens, the request was fraudulent, so you shouldn't process it!
Step 3: Inject for Next Time
Finally, once you've finished processing your html code and it's ready to send back to the client, you should inject the CSRF tokens. If you don't, the request will fail to pass Step 2 when the page gets submitted!
Using tokens of a different lengths
By default, 32 character tokens are generated. They use characters from the set [a-zA-Z0-9], meaning a 64-bit token which would take a brute-force attacker making 100,000 requests per second around 2.93 million years to guess. If this seems either excessive or inadequate you can change the token length using TokenStore::setTokenLength()
.
Special note about client-side requests
Note that if there are several forms on your page, a unique token will be generated and injected into each form. When a form is submitted using a client-side request (XMLHTTPRequest or Fetch, a.k.a. AJAX), the response will contain a new token that must be refreshed in the page ready for the next submission.
If you would prefer to have one token per page, shared across all forms, this can be configured by passing in the TOKEN_PER_PAGE parameter to the projectAndInject method: $page->protectAndInject(HTMLDocumentProtector::TOKEN_PER_PAGE);
.
Storing one token per page will reduce the amount of server resources required, but concurrent client-side requests will fail, which is why one token per form is the default.
Alternatives to storing tokens on the session
The package includes an ArrayTokenStore
, which can be stored on the session. You can implement alternative token stores such as a RDBMS or NoSQL by subclassing TokenStore
and implementing the abstract methods.