There are a multitude of examples on the internet for how OpenSSL CSR configuration files may look but I've yet to come across where the specs / attributes are actually standardized / declared.
Meta: this is not really a programming/development question and probably belongs on serverfault or maybe superuser.
There are four types of configuration used by openssl req to generate a CSR:
options or settings that control the operation of the req command itself, like the default size of key to generate (for RSA) or keyfile to write, and hash to use in signing
values that go in the subject Distinguished Name; these are usually prompted for from the user/terminal, but can be hardcoded, or overridden using option -subj
'attributes' (directly) in the CSR, see rfc2986, which use the same syntax as DN and can be prompted or hardcoded
requested extensions; these are actually all encapsulated into a single attribute with OID 1.2.840.113549.1.9.14, but because they correspond to extensions in a cert or CRL (where they are not in an attribute) OpenSSL configures them separately
The man page for req or in new versions possibly openssl-req on your system or on the web (other releases linked at right) describes the first group at the heading CONFIGURATION FILE FORMAT and the syntax for the second and third groups at DISTINGUISHED NAME AND ATTRIBUTE SECTION FORMAT.
Both the components of a DistinguishedName (aka DN, X501Name etc, which are themselves called attributes) and the attributes (if any) of a CSR are identified by ASN.1 Object Identifiers aka OIDs, making them in principle arbitrarily extensible, and so are extension values (see more below). In practice only a handful or two of OIDs are usually used for DN, and since a CSR is usually used to obtain an X.509 (or PKIX) cert and that cert is often used to interoperate with other program(s) or system(s) you usually don't want to use OIDs that will not be properly understood by the program(s) or system(s) you will or might want to interoperate with. Usually attributes other than extensionRequest aren't used at all but when they are used they are handled by the CA and usually don't go in the cert and thus don't matter for interoperability.
The OIDs normally used in PKIX certs for Subject DN are defined in rfc5280 section 4.1.2.6 partly by reference to the definition for Issuer in section 4.1.2.4 with the details of OIDs in the ASN.1 module in appendix A. Of course PKIX is not the only area that uses X.509 certs and you might be using OpenSSL to support some other application area that has different standards for naming.
There are over a dozen extension OIDs that are commonly used, and probably at least a hundred used in specialized areas, but most of them are put in the cert by the CA and can't be requested; there are probably only a handful that can usefully be put in a CSR. The extensions supported by OpenSSL, for both CSRs and certs, are defined in the man page for x509v3_config (as linked in the req page under req_extensions), along with a link to the syntax for defining 'arbitrary' extensions -- ones not already coded in OpenSSL. For arbitrary extensions, and possibly even for supported ones, you may want to define new named OIDs, rather than repeating the inconvenient and unmnemonic numeric forms; that is described in the man page for config.
The extensions commonly used in PKIX certs are defined in rfc 5280 section 4.2 but again non-PKIX certs may be different, and as noted most of the cert extensions don't make sense in a CSR.
Also note that the req command with the -x509 option, generates a cert and NOT a CSR; in that case the configuration for Subject DN and Extensions (actual extensions not requested) are used, but attributes are not, and different settings are used for controlling the command itself, like the validity time.