CWE-287
DiscouragedImproper Authentication
Abstraction: Class · Status: Draft
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
6634 vulnerabilities reference this CWE, most recent first.
GHSA-XWJM-QJ7J-73QW
Vulnerability from github – Published: 2022-05-01 23:36 – Updated: 2022-05-01 23:36OMEGA (aka Omegasoft) INterneSErvicesLosungen (INSEL) 7 supports authentication with a cookie that lacks a shared secret, which allows remote attackers to login as an arbitrary user via a modified cookie.
{
"affected": [],
"aliases": [
"CVE-2008-1134"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-03-04T19:44:00Z",
"severity": "MODERATE"
},
"details": "OMEGA (aka Omegasoft) INterneSErvicesLosungen (INSEL) 7 supports authentication with a cookie that lacks a shared secret, which allows remote attackers to login as an arbitrary user via a modified cookie.",
"id": "GHSA-xwjm-qj7j-73qw",
"modified": "2022-05-01T23:36:51Z",
"published": "2022-05-01T23:36:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-1134"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/39575"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/28410"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/486009/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/27210"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XWWR-4H3P-R22C
Vulnerability from github – Published: 2026-09-10 22:49 – Updated: 2026-09-10 22:49Summary
rclone serve s3's handler chain, when --auth-proxy is configured, is (outermost first): authPairMiddleware -> proxyAuthMiddleware -> gofakes3's own SigV4-verifying handler.
authPairMiddleware parses the accessKeyID straight out of the incoming request's own Authorization header (entirely client-controlled) and registers {accessKey: ws.s3Secret} into gofakes3's shared credential store via AddAuthKeys, for EVERY access key any client presents - not just ones previously known to the server. ws.s3Secret defaults to "" whenever --auth-key is not set, which the --auth-proxy documentation (and the reference bin/test_proxy.py) presents as a complete, standalone authentication mechanism requiring no other flag - matching how it's used for serve webdav/ftp/sftp.
gofakes3's SigV4 verification then checks the request's signature against exactly the secret authPairMiddleware just registered for that same client-chosen key. An empty string is a valid HMAC key, so a caller can trivially compute a correct SigV4 signature for ANY access key ID of their choosing using an empty secret, and verification passes.
Crucially, the auth-proxy script never receives a real secret to verify against, for S3 specifically: Server.auth() calls w.proxy.Call(md5(accessKeyID), accessKeyID, false, r.RemoteAddr) - passing the access key ID itself as BOTH the hashed "user" and the raw "auth"/password fields. Contrast with serve webdav/ftp/sftp, whose proxy integration passes the client's actual typed password (see bin/test_proxy.py, which forwards it into a backing SFTP login for real verification). For S3, no independent secret is ever transmitted to the proxy script at all, so no script - however carefully written - can distinguish a legitimate holder of an access key ID from an attacker who merely picked the same string.
Net effect: with --auth-proxy configured and --auth-key not also set (the configuration the feature is documented to support standalone), SigV4 signature verification authenticates nobody.
Details
Vulnerable code (before fix):
func authPairMiddleware(next http.Handler, ws *Server) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
accessKey, _ := parseAccessKeyID(r)
authPair := map[string]string{accessKey: ws.s3Secret}
ws.faker.AddAuthKeys(authPair)
next.ServeHTTP(w, r)
})
}
PoC
Built and signed a request by hand (via the vendored github.com/aws/aws-sdk-go-v2/aws/signer/v4) using a freshly-random access key ID never configured or returned by anything, with SecretAccessKey: "", against a real rclone serve s3 --auth-proxy <script> instance with no --auth-key set:
status=200
<ListAllMyBucketsResult>...<Bucket><Name>mybucket</Name>...
A fully authenticated, successful bucket listing, with zero prior credential knowledge.
Impact
Any network-reachable, unauthenticated attacker who knows (or discovers) that a target is running rclone serve s3 --auth-proxy without --auth-key can choose an arbitrary access key ID, sign a request against an empty secret, and be treated as an authenticated user by the auth-proxy script - reaching whatever backend that script resolves the chosen identity to. No credentials, prior access, or user interaction of any kind are required.
Fix
Refuse to start rclone serve s3 when --auth-proxy is set without --auth-key, rather than silently falling back to a signature check that authenticates nobody:
if proxyOpt.AuthProxy != "" && len(opt.AuthKey) == 0 {
return nil, errors.New("serve s3: --auth-proxy requires --auth-key to also be set (SigV4 has no other way to verify a signature for a dynamically-proxied identity)")
}
Note this is a minimal fix for the zero-knowledge bypass; once --auth-key is also set, every access key ID still shares that one static secret for signature-verification purposes (a caller who knows it can request any identity from the proxy script) - a narrower, pre-existing limitation flagged for awareness but not changed here, since a complete fix needs the auth-proxy wire protocol to carry a per-identity secret for S3 specifically (a larger design change).
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/rclone/rclone"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.75.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-88018"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T22:49:07Z",
"nvd_published_at": "2026-09-10T16:18:08Z",
"severity": "CRITICAL"
},
"details": "### Summary\n`rclone serve s3`\u0027s handler chain, when `--auth-proxy` is configured, is (outermost first): `authPairMiddleware` -\u003e `proxyAuthMiddleware` -\u003e gofakes3\u0027s own SigV4-verifying handler.\n\n`authPairMiddleware` parses the accessKeyID straight out of the incoming request\u0027s own `Authorization` header (entirely client-controlled) and registers `{accessKey: ws.s3Secret}` into gofakes3\u0027s shared credential store via `AddAuthKeys`, for EVERY access key any client presents - not just ones previously known to the server. `ws.s3Secret` defaults to `\"\"` whenever `--auth-key` is not set, which the `--auth-proxy` documentation (and the reference `bin/test_proxy.py`) presents as a complete, standalone authentication mechanism requiring no other flag - matching how it\u0027s used for `serve webdav`/`ftp`/`sftp`.\n\ngofakes3\u0027s SigV4 verification then checks the request\u0027s signature against exactly the secret `authPairMiddleware` just registered for that same client-chosen key. An empty string is a valid HMAC key, so a caller can trivially compute a correct SigV4 signature for ANY access key ID of their choosing using an empty secret, and verification passes.\n\nCrucially, the auth-proxy script never receives a real secret to verify against, for S3 specifically: `Server.auth()` calls `w.proxy.Call(md5(accessKeyID), accessKeyID, false, r.RemoteAddr)` - passing the access key ID itself as BOTH the hashed \"user\" and the raw \"auth\"/password fields. Contrast with `serve webdav`/`ftp`/`sftp`, whose proxy integration passes the client\u0027s actual typed password (see `bin/test_proxy.py`, which forwards it into a backing SFTP login for real verification). For S3, no independent secret is ever transmitted to the proxy script at all, so no script - however carefully written - can distinguish a legitimate holder of an access key ID from an attacker who merely picked the same string.\n\nNet effect: with `--auth-proxy` configured and `--auth-key` not also set (the configuration the feature is documented to support standalone), SigV4 signature verification authenticates nobody.\n\n### Details\nVulnerable code (before fix):\n```go\nfunc authPairMiddleware(next http.Handler, ws *Server) http.Handler {\n\treturn http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n\t\taccessKey, _ := parseAccessKeyID(r)\n\t\tauthPair := map[string]string{accessKey: ws.s3Secret}\n\t\tws.faker.AddAuthKeys(authPair)\n\t\tnext.ServeHTTP(w, r)\n\t})\n}\n```\n\n### PoC\nBuilt and signed a request by hand (via the vendored `github.com/aws/aws-sdk-go-v2/aws/signer/v4`) using a freshly-random access key ID never configured or returned by anything, with `SecretAccessKey: \"\"`, against a real `rclone serve s3 --auth-proxy \u003cscript\u003e` instance with no `--auth-key` set:\n```\nstatus=200\n\u003cListAllMyBucketsResult\u003e...\u003cBucket\u003e\u003cName\u003emybucket\u003c/Name\u003e...\n```\nA fully authenticated, successful bucket listing, with zero prior credential knowledge.\n\n### Impact\nAny network-reachable, unauthenticated attacker who knows (or discovers) that a target is running `rclone serve s3 --auth-proxy` without `--auth-key` can choose an arbitrary access key ID, sign a request against an empty secret, and be treated as an authenticated user by the auth-proxy script - reaching whatever backend that script resolves the chosen identity to. No credentials, prior access, or user interaction of any kind are required.\n\n### Fix\nRefuse to start `rclone serve s3` when `--auth-proxy` is set without `--auth-key`, rather than silently falling back to a signature check that authenticates nobody:\n```go\nif proxyOpt.AuthProxy != \"\" \u0026\u0026 len(opt.AuthKey) == 0 {\n\treturn nil, errors.New(\"serve s3: --auth-proxy requires --auth-key to also be set (SigV4 has no other way to verify a signature for a dynamically-proxied identity)\")\n}\n```\nNote this is a minimal fix for the zero-knowledge bypass; once `--auth-key` is also set, every access key ID still shares that one static secret for signature-verification purposes (a caller who knows it can request any identity from the proxy script) - a narrower, pre-existing limitation flagged for awareness but not changed here, since a complete fix needs the auth-proxy wire protocol to carry a per-identity secret for S3 specifically (a larger design change).",
"id": "GHSA-xwwr-4h3p-r22c",
"modified": "2026-09-10T22:49:07Z",
"published": "2026-09-10T22:49:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/security/advisories/GHSA-xwwr-4h3p-r22c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88018"
},
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/commit/90595f34f27f569be6b27c57fe5ab65057d323bd"
},
{
"type": "PACKAGE",
"url": "https://github.com/rclone/rclone"
},
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/releases/tag/v1.75.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "rclone serve s3: --auth-proxy without --auth-key authenticates nobody - full SigV4 signature bypass"
}
GHSA-XX2R-X7VM-XJJJ
Vulnerability from github – Published: 2022-04-05 00:00 – Updated: 2022-04-14 00:00A local authentication restriction bypass vulnerability was discovered in HPE OneView version(s): Prior to 6.6. HPE has provided a software update to resolve this vulnerability in HPE OneView.
{
"affected": [],
"aliases": [
"CVE-2022-23699"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-04T20:15:00Z",
"severity": "HIGH"
},
"details": "A local authentication restriction bypass vulnerability was discovered in HPE OneView version(s): Prior to 6.6. HPE has provided a software update to resolve this vulnerability in HPE OneView.",
"id": "GHSA-xx2r-x7vm-xjjj",
"modified": "2022-04-14T00:00:42Z",
"published": "2022-04-05T00:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23699"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbgn04252en_us"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XX6M-M9V2-VC78
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-10-24 19:00Attackers can access the CGE account management function without privilege for permission elevation and execute arbitrary commands or files after obtaining user permissions.
{
"affected": [],
"aliases": [
"CVE-2021-22858"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-434"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-17T11:15:00Z",
"severity": "HIGH"
},
"details": "Attackers can access the CGE account management function without privilege for permission elevation and execute arbitrary commands or files after obtaining user permissions.",
"id": "GHSA-xx6m-m9v2-vc78",
"modified": "2022-10-24T19:00:18Z",
"published": "2022-05-24T17:42:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22858"
},
{
"type": "WEB",
"url": "https://www.chtsecurity.com/news/fe1e30ef-4dac-4848-a3c9-a7df12672422"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-4396-e6d44-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XX73-XG4M-9C9J
Vulnerability from github – Published: 2022-05-24 17:19 – Updated: 2022-05-24 17:19An issue was discovered on Samsung mobile devices with P(9.0) and Q(10.0) software. The DeX Lockscreen feature does not block access to Quick Panel and notifications. The Samsung ID is SVE-2020-17187 (June 2020).
{
"affected": [],
"aliases": [
"CVE-2020-13838"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-06-04T18:15:00Z",
"severity": "LOW"
},
"details": "An issue was discovered on Samsung mobile devices with P(9.0) and Q(10.0) software. The DeX Lockscreen feature does not block access to Quick Panel and notifications. The Samsung ID is SVE-2020-17187 (June 2020).",
"id": "GHSA-xx73-xg4m-9c9j",
"modified": "2022-05-24T17:19:21Z",
"published": "2022-05-24T17:19:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13838"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XXC2-J7JJ-6G5M
Vulnerability from github – Published: 2022-08-05 00:00 – Updated: 2022-08-11 21:14An issue in Renato v0.17.0 allows attackers to cause a Denial of Service (DoS) via a crafted payload injected into the Search parameter.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.17.0"
},
"package": {
"ecosystem": "npm",
"name": "raneto"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.17.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-35142"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2022-08-11T21:14:43Z",
"nvd_published_at": "2022-08-04T20:15:00Z",
"severity": "HIGH"
},
"details": "An issue in Renato v0.17.0 allows attackers to cause a Denial of Service (DoS) via a crafted payload injected into the `Search` parameter.",
"id": "GHSA-xxc2-j7jj-6g5m",
"modified": "2022-08-11T21:14:43Z",
"published": "2022-08-05T00:00:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35142"
},
{
"type": "WEB",
"url": "https://github.com/ryanlelek/Raneto/issues/368"
},
{
"type": "WEB",
"url": "https://github.com/ryanlelek/Raneto/pull/370"
},
{
"type": "WEB",
"url": "https://cwe.mitre.org/data/definitions/703.html"
},
{
"type": "WEB",
"url": "https://gainsec.com/2022/08/04/cve-2022-35142-cve-2022-35143-cve-2022-35144"
},
{
"type": "WEB",
"url": "https://github.com/gilbitron/Raneto/releases"
},
{
"type": "PACKAGE",
"url": "https://github.com/ryanlelek/Raneto"
},
{
"type": "WEB",
"url": "https://github.com/ryanlelek/Raneto/releases/tag/0.17.1"
},
{
"type": "WEB",
"url": "http://raneto.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Raneto Denial of Service via crafted payload injected into `Search` parameter"
}
GHSA-XXCH-H4GF-8FH3
Vulnerability from github – Published: 2022-05-17 03:59 – Updated: 2022-05-17 03:59Advantech EKI-132x devices with firmware before 2015-12-31 allow remote attackers to bypass authentication via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2015-7938"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-01-09T02:59:00Z",
"severity": "CRITICAL"
},
"details": "Advantech EKI-132x devices with firmware before 2015-12-31 allow remote attackers to bypass authentication via unspecified vectors.",
"id": "GHSA-xxch-h4gf-8fh3",
"modified": "2022-05-17T03:59:36Z",
"published": "2022-05-17T03:59:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-7938"
},
{
"type": "WEB",
"url": "https://ics-cert.us-cert.gov/advisories/ICSA-15-344-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XXF7-9X7M-J4R3
Vulnerability from github – Published: 2026-08-22 06:31 – Updated: 2026-08-23 18:31The WP Social Media Login WordPress plugin through 1.0.6 does not verify that a social login was actually completed with the identity provider before authenticating a visitor, allowing unauthenticated attackers to log in as any existing user, including administrators, by supplying that user's email address.
{
"affected": [],
"aliases": [
"CVE-2026-77000"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-22T06:16:17Z",
"severity": "CRITICAL"
},
"details": "The WP Social Media Login WordPress plugin through 1.0.6 does not verify that a social login was actually completed with the identity provider before authenticating a visitor, allowing unauthenticated attackers to log in as any existing user, including administrators, by supplying that user\u0027s email address.",
"id": "GHSA-xxf7-9x7m-j4r3",
"modified": "2026-08-23T18:31:44Z",
"published": "2026-08-22T06:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77000"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/3051dece-7ecb-4911-bf13-291ebdc34bff"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XXMG-8G8R-G92F
Vulnerability from github – Published: 2023-03-28 21:30 – Updated: 2023-04-05 15:30Osprey Pump Controller version 1.01 could allow an unauthenticated user to create an account and bypass authentication, thereby gaining unauthorized access to the system. A threat actor could exploit this vulnerability to create a user account without providing valid credentials. A threat actor who successfully exploits this vulnerability could gain access to the pump controller and cause disruption in operation, modify data, or shut down the controller.
{
"affected": [],
"aliases": [
"CVE-2023-28398"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-28T21:15:00Z",
"severity": "CRITICAL"
},
"details": "Osprey Pump Controller version 1.01 could allow an unauthenticated user to create an account and bypass authentication, thereby gaining unauthorized access to the system. A threat actor could exploit this vulnerability to create a user account without providing valid credentials. A threat actor who successfully exploits this vulnerability could gain access to the pump controller and cause disruption in operation, modify data, or shut down the controller.",
"id": "GHSA-xxmg-8g8r-g92f",
"modified": "2023-04-05T15:30:25Z",
"published": "2023-03-28T21:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28398"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-082-06"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XXPF-83G5-3W2V
Vulnerability from github – Published: 2022-05-17 05:40 – Updated: 2022-05-17 05:40TCPUploadServer.exe in Progea Movicon 11.2 before Build 1084 does not require authentication for critical functions, which allows remote attackers to obtain sensitive information, delete files, execute arbitrary programs, or cause a denial of service (crash) via a crafted packet to TCP port 10651.
{
"affected": [],
"aliases": [
"CVE-2011-2963"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-07-29T19:55:00Z",
"severity": "HIGH"
},
"details": "TCPUploadServer.exe in Progea Movicon 11.2 before Build 1084 does not require authentication for critical functions, which allows remote attackers to obtain sensitive information, delete files, execute arbitrary programs, or cause a denial of service (crash) via a crafted packet to TCP port 10651.",
"id": "GHSA-xxpf-83g5-3w2v",
"modified": "2022-05-17T05:40:11Z",
"published": "2022-05-17T05:40:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-2963"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/17034"
},
{
"type": "WEB",
"url": "http://www.osvdb.org/72888"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/46907"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/control_systems/pdf/ICSA-11-056-01.pdf"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/control_systems/pdf/ICSA-11-056-01A.pdf"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Strategy: Libraries or Frameworks
Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
CAPEC-114: Authentication Abuse
An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.
CAPEC-115: Authentication Bypass
An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.
CAPEC-151: Identity Spoofing
Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.
CAPEC-194: Fake the Source of Data
An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-593: Session Hijacking
This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.
CAPEC-633: Token Impersonation
An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.
CAPEC-650: Upload a Web Shell to a Web Server
By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.