HTTP Installing protection on a page using MySQL and PHP. HTTP Setting security on a page using MySQL and PHP PHP code to create two-level authentication

Restricting access to any area of ​​the site usually looks like
monotonous: each user is given a login and password or he himself
selects them, and to enter the secure part of the site they must be entered. From a technical point of view, to check the password they use
different methods. An HTML form can be used to enter your login and password.
In this case, the password is sent to the server in clear text in the POST request.
This is unacceptable if the user is local, where possible
using a sniffer. To solve this problem, a method was invented
authentication using hashes, in which the password is not transmitted, but
a hash string is transmitted, depending on the password, some one-time
parameter and, possibly, from some other parameters. This method is also
called challenge/response, because when using it the client
receives a request with a one-time parameter and sends a response containing the hash. At the level HTTP protocol 1.1 authentication method possible
Basic, which is no better than using an HTML form, and Digest, which
we will look at it in detail.

When using the Digest method, as already mentioned, the password
is not transmitted and cannot be sniffed, but there is another side
Problems. In order to check the password, the server must calculate
response and compare it with the client response, therefore the server must
store the password or data dependent on it necessary for
passing authentication. It follows that a person who has received rights
to read accounts (for example, using SQL injection), will be able to get
access to pages protected by the Digest method. When using the method
Basic, it is possible to store hashes instead of passwords, which does not allow you to raise rights,
after reading these hashes (we will see below that Digest can also store hashes,
but such that their knowledge is sufficient to calculate the answer). Thus, we are faced with a dilemma: either our password will be sniffed,
or they will get it through a web vulnerability, which someone will definitely find,
because whoever seeks will always find. There is an authentication method without
Both of these disadvantages are the public key authentication method:
needed for verification public key, and to pass the verification - secret,
however, HTTP 1.1 does not provide such a method. RFC 2069
recommends using SSL if security is so important. Only the transmission of the password is protected, and the content is not encrypted, so
that there is no point in protecting resources with this method, where the user is from
receives secret information. They require SSL. And it makes sense
protect, for example, a forum or uploading content to a website. So, if the hosting does not support SSL, and authentication must
to be safe, we will use Digest. Apache provides the mod_digest module. To use it
in the config (or in .htaccess) we write:

AuthType Digest
AuthUserFile
AuthName
Require valid_user

User files are created by the utility
htdigest. At one time there were reports about mod_digest that it was vulnerable, so
Perhaps some other problems will appear there. Moreover, when
I tried to use it at home, I got an error
500 Server Internal Error. Additionally, if adding accounts should occur
automatically, and there should be a lot of them, they should
stored not in the Apache config, but in MySQL. Solution -
use PHP. PHP doesn't have built-in support for this
method, so it will have to be implemented. To do this you need to study
this method in detail. Let me immediately note that the information given in this article
the implementation only works on Apache, since full access to headings
request (apache_request_headers function) only works in Apache, but on
may not be available on other servers. We just need to read
Authorization header.

Description of the method

The full description of the method can be read in RFC 2069, and if
In short, the method works like this. When the server receives a request related to the protected area,
it throws error 401 Authorization Required and request header
authentication of this type:

WWW-Authenticate: Digest realm="secure area", nonce="123456123456"

realm is the name of the protected area, and nonce is a one-time use
meaning. There are also optional parameters that we will discuss
we will not. The client repeats the request, adding a header like this:

Authorization: Digest realm="secure area", username="123", uri="/index.php", nonce="123456123456", response="1234567890abcdef1234567890abcdef"

The uri parameter must match the URI in the request, and the response is
the answer, which is calculated like this:

response = H(H(A1) + ":" + nonce + ":" + H(A2))
H - hash function, default MD5
A1 = login + ":" + realm + ":" + password
A2 = request method + ":" + URI
The request method is GET, POST, etc.

As we can see, A1 does not depend on either the request or the one-time
values, so the server can store not a password, but
H(A1). This is exactly how it is implemented in mod_digest in Apache.
However, the same data is sufficient for the client. The attacker, having received
this hash can calculate the answer using the above formulas and
generate an HTTP request, for example, using the program
AccessDriver and its HTTP tool
Debugger. This process will be shown in more detail below. The server should check if the value is a nonce
the one that was previously issued to the client and whether it is out of date.
If the response matches the nonce parameter, but the value of that parameter
not relevant, the response described above with code 401 is issued only because
the difference is that the parameter is added to the WWW-Authenticate header
stale=true, indicating that access is denied for this reason only,
and should try again without prompting the user New Password. This, IMHO, is inconvenient, because if such a situation arises
when making a POST or PUT request with a large block of data, the client will have to
transmit all data twice. To avoid this, the standard provides
Authentication-Info header, in which the server may respond to
successful request to tell the client the next nonce.
The syntax is the same as WWW-Authenticate, except that the nonce
is replaced by nextnonce. However, judging by the results of my
experiments, Opera ignores this header. Another solution: according to
RFC 2068 (HTTP/1.1), the server may respond before the request completes,
so that the client interrupts unnecessary data transfer, but in Apache+PHP this
is not implemented, since the script starts executing only after
how Apache will fully receive and parse the request.

Storing data between requests

There is a subtle point in implementing the challenge/response method in PHP.
A one-time parameter is generated and issued to the client in one response, and
is checked in another session of the script.
That is, it must be saved from one script call to another, and for this you will have to
use files or database. My example uses files named
corresponding to one-time values, and the files themselves contain
IP addresses of the clients to whom they are issued. Collection is not implemented in the example
garbage: you need to periodically delete old files.

Code parsing

This script only checks the password, and works regardless of
login Depending on the success of the check, simple answers are given.