如何使用LDAP安全地驗證用戶身份？-有解無憂

對于背景關系：我正在開發一個 Web 應用程式，用戶需要在其中進行身份驗證才能查看內部檔案。我不需要任何有關用戶的詳細資訊，也不需要特殊權限管理，兩種狀態就足夠了：會話屬于經過身份驗證的用戶（→ 檔案可以訪問）或不屬于（→ 檔案無法訪問）。用戶通過提供用戶名和密碼進行身份驗證，我想檢查 LDAP 服務器。

我正在使用 Python 3.10 和ldap3Python 庫。

編碼

我目前正在使用以下代碼對用戶進行身份驗證：

#!/usr/bin/env python3
import ssl

from ldap3 import Tls, Server, Connection
from ldap3.core.exceptions import LDAPBindError, LDAPPasswordIsMandatoryError


def is_valid(username: str, password: str) -> bool:
    tls_configuration = Tls(validate=ssl.CERT_REQUIRED)
    server = Server("ldaps://ldap.example.com", tls=tls_configuration)
    user_dn = f"cn={username},ou=ops,dc=ldap,dc=example,dc=com"

    try:
        with Connection(server, user=user_dn, password=password):
            return True
    except (LDAPBindError, LDAPPasswordIsMandatoryError):
        return False

演示實體

如果要運行此代碼，可以嘗試使用FreeIPA 的專案演示 LDAP 服務器。

替換CERT_REQUIRED為，CERT_NONE因為服務器僅提供自簽名證書（這顯然是一個安全漏洞，但需要使用此特定演示 - 我要使用的服務器使用 Let's Encrypt 證書）。
替換"ldaps://ldap.example.com"為ldaps://ipa.demo1.freeipa.org
替換user_dn為f"uid={username},cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org"

這樣做之后，您可以嘗試運行以下命令：

>>> is_valid("admin", "Secret123")
True
>>> is_valid("admin", "Secret1234")
False
>>> is_valid("admin", "")
False
>>> is_valid("admin", None)
False
>>> is_valid("nonexistent", "Secret123")
False

我的問題

上面的代碼是否可以安全地確定用戶是否提供了有效的憑據？

值得注意的是，我擔心以下特定方面：

嘗試系結到 LDAP 服務器是否足以驗證憑據？
- with僅當系結成功時才應執行陳述句的主體，因此True無需多言就回傳。這安全嗎？或者是否有可能系結成功，但提供的密碼仍然被認為是錯誤的，不足以針對 Web 應用程式對用戶進行身份驗證。
我是否對注射攻擊敞開心扉？如果是這樣，如何正確緩解它們？
- user_dn = f"cn={username},ou=ops,dc=ldap,dc=example,dc=com"使用不受信任 username的（直接來自網路表單）來構建字串。這基本上是在尖叫 LDAP 注入。
TLS 是否正確配置？
- 連接應該使用現代 TLS 加密并驗證服務器提供的證書，就像普通瀏覽器一樣。

另外，當然，如果我的代碼還有其他不安全的地方，我很樂意知道它是什么。

我已經找到的資源

我已經搜索了特定方面的答案。可悲的是，我沒有找到任何確定的東西（即沒有人肯定地說我在這里做的事情是壞的還是好的），但我想提供它們作為潛在答案的起點：

大概是。
- “How to bind (authenticate) a user with ldap3 in python3”使用了類似的代碼片段來系結，沒有人明確說這很糟糕。
- Auth0 在他們的博客文章“將 LDAP 和 Active Directory 與 C# 101 一起使用”中使用了這種方法，他們可能知道自己在做什么。
可能不會，所以不需要緩解。
- 關于 LDAP 注入有一些問題（例如“如何防止 ldap3 for python3 中的 LDAP 注入”），但它們總是只提到過濾和搜索，而不是系結。
- OWASP Cheat Sheet on LDAP Injection提到啟用系結身份驗證作為一種在過濾時減輕 LDAP 注入的方法，但沒有提及系結 DN 所需的清理。
- 我想你甚至可以爭辯說這種情況不容易受到注入攻擊，因為我們確實在處理不受信任的輸入，但只在預期不受信任的輸入的地方。任何人都可以在登錄表單中輸入任何內容，但他們也可以將任何內容放入請求中以系結到 LDAP 服務器（甚至無需使用 Web 應用程式）。只要我不將不受信任的輸入放在預期受信任輸入的地方（例如，在與 LDAP 管理員帳戶系結后在過濾器查詢中使用用戶名），我應該是安全的。
- 但是，該物件的ldap3檔案Connection確實提到了escape_rdn與不受信任的用戶名系結時應該使用的內容。這與我的假設不一致，誰是對的？
大概是。
- 當我嘗試將此代碼與僅提供自簽名證書的服務器一起使用時，至少引發了一個錯誤，所以我想我應該是安全的。

uj5u.com熱心網友回復：

嘗試系結到 LDAP 服務器是否足以驗證憑據？

從 LDAP 協議方面來看，是的，并且許多系統已經依賴于這種行為（例如，針對 LDAP 服務器的 Linux 作業系統級別身份驗證的 pam_ldap）。我從未聽說過任何將系結結果推遲到另一個操作的服務器。

.bind()從 ldap3 模塊方面我會更擔心，因為根據我初始化連接的經驗，在我明確呼叫（或者除非我指定 auto_bind=True）之前，我沒有嘗試連接（更不用說系結）到服務器，但是如果你的示例作業然后我假設使用一個with塊可以正確地做到這一點。

在舊代碼中（它擁有一個持久連接，沒有'with'）我使用過這個，但它可能已經過時了：

conn = ldap3.Connection(server, raise_exceptions=True)
conn.bind()

（對于某些應用程式，我使用 Apache 作為反向代理，它的 mod_auth_ldap 為我處理 LDAP 身份驗證，尤其是在“已通過身份驗證”就足夠的情況下。）

我是否對注射攻擊敞開心扉？如果是這樣，如何正確緩解它們？

嗯，有點，但不是以一種容易被利用的方式。系結 DN 不是一個自由格式的查詢——它只是一個看起來很奇怪的“用戶名”欄位，它必須與現有條目完全匹配；你不能在里面放通配符。

（嚴格“系結”操作接受什么符合 LDAP 服務器的最大利益，因為它實際上是在完成任何其他操作之前登錄 LDAP 服務器的面向用戶的操作——它不僅僅是一個“密碼檢查”功能。 )

例如，如果您在 OU=Ops 有一些用戶，而在 OU=Superops,OU=Ops 有一些用戶，那么有人可以將Foo,OU=Superops其用戶名指定為UID=Foo,OU=Superops,OU=Ops,DN，但他們仍然必須為該帳戶提供正確的密碼反正; 他們不能在檢查另一個帳戶的密碼時欺騙服務器使用一個帳戶的權限。

但是，無論如何，很容易避免注入。可以使用以下方法轉義 DN 組件值：

ldap3：ldap3.utils.dn.escape_rdn(string)
蟒蛇ldap：ldap.dn.escape_dn_chars(string)

話雖如此，我不喜歡“DN 模板”方法的原因完全不同——它的用處相當有限；它僅在您的所有帳戶都在同一個 OU（平面層次結構）下并且僅當它們以uid屬性命名時才有效。

這可能是專門構建的 LDAP 目錄的情況，但在典型的 Microsoft Active Directory 服務器上（或者，我相信，在某些 FreeIPA 服務器上也是如此），用戶帳戶條目以其全名（cn屬性）命名，并且可以分散在許多 OU 中。兩步法更常見：

使用您的應用程式的服務憑據進行系結，然后在目錄中搜索其uid屬性中包含用戶名或類似名稱的任何“用戶”條目，并驗證您是否找到了一個條目；
取消系結（可選？），然后使用用戶找到的DN 和提供的密碼再次系結。

搜索時，您確實需要擔心 LDAP 過濾器注入攻擊，因為類似的用戶名foo)(uid=*可能會產生不良結果。（但要求結果完全匹配 1 個條目——而不是“至少 1 個”——也有助于緩解這種情況。）

可以使用以下方法轉義過濾器值：

ldap3：ldap3.utils.conv.escape_filter_chars(string)
蟒蛇ldap：ldap.filter.escape_filter_chars(string)

（python-ldap 也有一個方便的包裝器ldap.filter.filter_format，但它基本上只是the_filter % tuple(map(escape_filter_chars, args)).）

過濾器值的轉義規則與 RDN 值的轉義規則不同，因此您需要針對特定??背景關系使用正確的轉義規則。但至少與 SQL 不同，它們在任何地方都完全相同，因此 LDAP 客戶端模塊附帶的功能適用于任何服務器。

TLS 是否正確配置？

ldap3/core/tls.py 在我看來不錯——它在支持時使用 ssl.create_default_context()，加載系統默認 CA 證書，因此不需要額外配置。盡管它確實實作了自定義主機名檢查，而不是依賴于 ssl 模塊的 check_hostname，所以這有點奇怪。（也許 LDAP-over-TLS 規范定義了與通常的 HTTP-over-TLS 稍有不兼容的通配符匹配規則。）

替代手動轉義 DN 模板的替代方法：

dn = build_dn({"CN": f"{last}, {first} ({username})"},
              {"OU": "Faculty of Foo and Bar (XYZF)"},
              {"OU": "Staff"},
              ad.BASE_DN)

def build_dn(*args):
    components = []
    for rdn in args:
        if isinstance(rdn, dict):
            rdn = [(a, ldap.dn.escape_dn_chars(v))
                   for a, v in rdn.items()]
            rdn.sort()
            rdn = " ".join(["%s=%s" % av for av in rdn])
            components.append(rdn)
        elif isinstance(rdn, str):
            components.append(rdn)
        else:
            raise ValueError("Unacceptable RDN type for %r" % (rdn,))
    return ",".join(components)

轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/508175.html

標籤：Python ssl LDAP 代码注入 ldap3

上一篇：Letsencrypt的通配符SSL-好的，但CN仍然是“domain.com”而不是“*.domain.com”

下一篇：REST和TLS/SSL等基于Web的API之間有什么關系？