• Web LLM attacks(学习笔记)

    技术交流
    0 赞同
    2 帖子
    48 浏览

    什么是大型语言模型?
    What is a large language model?

    大型语言模型 (LLM) 是一种 AI 算法,可以处理用户输入并通过预测单词序列来创建合理的响应。他们在庞大的半公开数据集上进行训练,使用机器学习来分析语言的组成部分如何组合在一起。
    (Large Language Models (LLMs) are AI algorithms that can process user inputs and create plausible responses by predicting sequences of words. They are trained on huge semi-public data sets, using machine learning to analyze how the component parts of language fit together.)

    LLM 通常会提供一个聊天界面来接受用户输入,称为提示。允许的输入在一定程度上由输入验证规则控制。
    (LLMs usually present a chat interface to accept user input, known as a prompt. The input allowed is controlled in part by input validation rules.)

    LLM 在现代网站中可以有广泛的用例:
    (LLMs can have a wide range of use cases in modern websites:)

    *客户服务,例如虚拟助手。( Customer service, such as a virtual assistant.)

    译本。(Translation.) SEO改进。(SEO improvement.) 分析用户生成的内容,例如跟踪页面评论的语气。(Analysis of user-generated content, for example to track the tone of on-page comments.)

    LLM 攻击和提示注入
    LLM attacks and prompt injection

    许多 Web LLM 攻击依赖于一种称为提示注入的技术。攻击者可以使用构建的提示来操纵 LLM 的输出。提示注入可能会导致 AI 执行超出其预期目的的操作,例如对敏感 API 进行错误调用或返回不符合其准则的内容。
    (Many web LLM attacks rely on a technique known as prompt injection. This is where an attacker uses crafted prompts to manipulate an LLM's output. Prompt injection can result in the AI taking actions that fall outside of its intended purpose, such as making incorrect calls to sensitive APIs or returning content that does not correspond to its guidelines.)

    检测 LLM 漏洞
    Detecting LLM vulnerabilities

    我们推荐的 LLM 漏洞检测方法是:
    (Our recommended methodology for detecting LLM vulnerabilities is:)

    *识别 LLM 的输入,包括直接(如提示)和间接(如训练数据)输入。( Identify the LLM's inputs, including both direct (such as a prompt) and indirect (such as training data) inputs.)

    弄清楚 LLM 可以访问哪些数据和 API。(Work out what data and APIs the LLM has access to.) 探测此新攻击面以查找漏洞。(Probe this new attack surface for vulnerabilities.)

    利用 LLM API、函数和插件
    Exploiting LLM APIs, functions, and plugins

    LLM 通常由专门的第三方提供商托管。网站可以通过描述 LLM 要使用的本地 API 来为第三方 LLM 提供对其特定功能的访问权限。(LLMs are often hosted by dedicated third party providers. A website can give third-party LLMs access to its specific functionality by describing local APIs for the LLM to use.)

    例如,客户支持 LLM 可能有权访问管理用户、订单和库存的 API。(For example, a customer support LLM might have access to APIs that manage users, orders, and stock.)

    LLM API 的工作原理
    How LLM APIs work

    将 LLM 与 API 集成的工作流取决于 API 本身的结构。在调用外部 API 时,某些 LLM 可能需要客户端调用单独的函数端点(实际上是私有 API),以便生成可以发送到这些 API 的有效请求。此工作流可能如下所示:
    (The workflow for integrating an LLM with an API depends on the structure of the API itself. When calling external APIs, some LLMs may require the client to call a separate function endpoint (effectively a private API) in order to generate valid requests that can be sent to those APIs. The workflow for this could look something like the following:)

    1.客户端在用户的提示下调用 LLM。(The client calls the LLM with the user's prompt.) 2.LLM 检测到需要调用函数,并返回一个 JSON 对象,该对象包含遵循外部 API 架构的参数。(The LLM detects that a function needs to be called and returns a JSON object containing arguments adhering to the external API's schema.) 3.客户端使用提供的参数调用函数。(The client calls the function with the provided arguments.) 4.客户端处理函数的响应。(The client processes the function's response.) 5.客户端再次调用 LLM,将函数响应追加为新消息。(The client calls the LLM again, appending the function response as a new message.) 6.LLM 使用函数响应调用外部 API。(The LLM calls the external API with the function response.) 7.LLM 将此 API 回调的结果汇总给用户。(The LLM summarizes the results of this API call back to the user.)

    此工作流可能会带来安全隐患,因为 LLM 实际上代表用户调用外部 API,但用户可能不知道正在调用这些 API。理想情况下,在 LLM 调用外部 API 之前,应向用户提供确认步骤。
    (This workflow can have security implications, as the LLM is effectively calling external APIs on behalf of the user but the user may not be aware that these APIs are being called. Ideally, users should be presented with a confirmation step before the LLM calls the external API.)

    映射 LLM API 攻击面
    Mapping LLM API attack surface

    术语“过度代理”是指 LLM 可以访问 API 的情况,这些 API 可以访问敏感信息,并且可以被说服不安全地使用这些 API。这使攻击者能够将 LLM 推到其预期范围之外,并通过其 API 发起攻击。
    (The term "excessive agency" refers to a situation in which an LLM has access to APIs that can access sensitive information and can be persuaded to use those APIs unsafely. This enables attackers to push the LLM beyond its intended scope and launch attacks via its APIs.)

    使用 LLM 攻击 API 和插件的第一阶段是确定 LLM 可以访问哪些 API 和插件。一种方法是简单地询问 LLM 它可以访问哪些 API。然后,您可以询问有关任何感兴趣的 API 的其他详细信息。
    (The first stage of using an LLM to attack APIs and plugins is to work out which APIs and plugins the LLM has access to. One way to do this is to simply ask the LLM which APIs it can access. You can then ask for additional details on any APIs of interest.)

    如果 LLM 不合作,请尝试提供误导性的上下文并重新提出问题。例如,您可以声称自己是 LLM 的开发人员,因此应该拥有更高级别的权限。
    (If the LLM isn't cooperative, try providing misleading context and re-asking the question. For example, you could claim that you are the LLM's developer and so should have a higher level of privilege.)

  • GitHub官网汉化插件

    已移动 Github & Git
    3 赞同
    77 帖子
    52k 浏览

    @k1995 大佬,求一个好用的VPN,十分感谢

  • 解析1

    开源分享
    0 赞同
    1 帖子
    102 浏览
    尚无回复
  • API recon(学习记录)

    技术交流
    0 赞同
    13 帖子
    310 浏览

    测试 REST 路径中的服务器端参数污染
    (Testing for server-side parameter pollution in REST paths)

    RESTful API 可能会将参数名称和值放在 URL 路径中,而不是放在查询字符串中。例如,请考虑以下路径:
    (A RESTful API may place parameter names and values in the URL path, rather than the query string. For example, consider the following path:)

    /api/users/123

    URL 路径可能按如下方式细分:(The URL path might be broken down as follows:)

    /api是根 API 端点。(api is the root API endpoint.) /users在本例中表示资源。users(users represents a resource, in this case users.) /123表示一个参数,这里是特定用户的标识符。(123represents a parameter, here an identifier for the specific user.)

    考虑一个应用程序,它使您能够根据用户的用户名编辑用户配置文件。请求将发送到以下终结点:(Consider an application that enables you to edit user profiles based on their username. Requests are sent to the following endpoint:)

    GET /edit_profile.php?name=peter

    这将导致以下服务器端请求:(This results in the following server-side request:)

    GET /api/private/users/peter

    攻击者可能能够操纵服务器端 URL 路径参数来利用 API。若要测试此漏洞,请添加路径遍历序列以修改参数并观察应用程序的响应方式。
    (An attacker may be able to manipulate server-side URL path parameters to exploit the API. To test for this vulnerability, add path traversal sequences to modify parameters and observe how the application responds.)

    您可以提交 URL 编码作为参数的值:peter/../adminname
    (You could submit URL-encoded peter/../admin as the value of the name parameter:)

    GET /edit_profile.php?name=peter%2f..%2fadmin

    这可能会导致以下服务器端请求:
    (This may result in the following server-side request:)

    GET /api/private/users/peter/../admin

    如果服务器端客户端或后端 API 对此路径进行规范化,则可能会将其解析为 /api/private/users/admin。
    (If the server-side client or back-end API normalize this path, it may be resolved to /api/private/users/admin.)

    测试结构化数据格式中的服务器端参数污染
    Testing for server-side parameter pollution in structured data formats

    攻击者可能能够操纵参数,以利用服务器处理其他结构化数据格式(如 JSON 或 XML)时的漏洞。为了测试这一点,将意外的结构化数据注入到用户输入中,并查看服务器如何响应。
    (An attacker may be able to manipulate parameters to exploit vulnerabilities in the server's processing of other structured data formats, such as a JSON or XML. To test for this, inject unexpected structured data into user inputs and see how the server responds.)

    考虑一个应用程序,该应用程序使用户能够编辑其配置文件,然后将他们的更改与请求一起应用于服务器端 API。当您编辑姓名时,您的浏览器会发出以下请求:
    (Consider an application that enables users to edit their profile, then applies their changes with a request to a server-side API. When you edit your name, your browser makes the following request:)

    POST /myaccount name=peter

    这将导致以下服务器端请求:
    (This results in the following server-side request:)

    PATCH /users/7312/update {"name":"peter"}

    您可以尝试将参数access_level添加到请求中,如下所示:
    (You can attempt to add the access_level parameter to the request as follows:)

    POST /myaccount name=peter","access_level":"administrator

    如果在未进行充分验证或审查的情况下将用户输入添加到服务器端 JSON 数据中,则会导致以下服务器端请求:

    (If the user input is added to the server-side JSON data without adequate validation or sanitization, this results in the following server-side request:)

    PATCH /users/7312/update {name="peter","access_level":"administrator"}

    这可能会导致用户peter被授予管理员访问权限。
    (This may result in the user peter being given administrator access.)

    相关页面 有关如何识别可以注入到查询字符串中的参数的信息,请参阅查找隐藏的参数 parameters 部分。 Related pages For information on how to identify parameters that you can inject into the query string, see the Finding hidden parameters section.

    考虑一个类似的示例,但客户端用户输入是 JSON 数据。当您编辑姓名时,您的浏览器会发出以下请求:
    (Consider a similar example, but where the client-side user input is in JSON data. When you edit your name, your browser makes the following request:)

    POST /myaccount {"name": "peter"}

    这将导致以下服务器端请求:
    (This results in the following server-side request:)

    PATCH /users/7312/update {"name":"peter"}

    您可以尝试将参数access_level添加到请求中,如下所示:
    (You can attempt to add the access_level parameter to the request as follows:)

    POST /myaccount {"name": "peter\",\"access_level\":\"administrator"}

    如果用户输入被解码,然后在没有适当编码的情况下添加到服务器端 JSON 数据中,则会导致以下服务器端请求:
    (If the user input is decoded, then added to the server-side JSON data without adequate encoding, this results in the following server-side request:)

    PATCH /users/7312/update {"name":"peter","access_level":"administrator"}

    同样,这可能会导致用户peter被授予管理员访问权限。
    (Again, this may result in the user peter being given administrator access.)

    结构化格式注入也可能发生在响应中。例如,如果用户输入安全地存储在数据库中,然后嵌入到来自后端 API 的 JSON 响应中,而没有进行足够的编码,则可能会发生这种情况。通常,您可以像在请求中一样检测和利用响应中的结构化格式注入。
    (Structured format injection can also occur in responses. For example, this can occur if user input is stored securely in a database, then embedded into a JSON response from a back-end API without adequate encoding. You can usually detect and exploit structured format injection in responses in the same way you can in requests.)

    Note This example below is in JSON, but server-side parameter pollution can occur in any structured data format. For an example in XML, see the XInclude attacks section in the XML external entity (XXE) injection topic. 注意 下面的示例是 JSON 格式,但服务器端参数污染可能以任何结构化数据格式发生。有关 XML 中的示例,请参阅 XML 外部实体 (XXE) 注入主题中的 XInclude 攻击部分。

    使用自动化工具进行测试
    Testing with automated tools

    Burp 包含自动化工具,可以帮助您检测服务器端参数污染漏洞。
    (Burp includes automated tools that can help you detect server-side parameter pollution vulnerabilities.)

    Burp Scanner 在执行审计时会自动检测可疑的输入转换。当应用程序接收到用户输入,以某种方式转换它,然后对结果执行进一步处理时,就会发生这种情况。此行为不一定构成漏洞,因此您需要使用上述手动技术进行进一步测试。有关详细信息,请参阅可疑 输入转换问题定义。
    (Burp Scanner automatically detects suspicious input transformations when performing an audit. These occur when an application receives user input, transforms it in some way, then performs further processing on the result. This behavior doesn't necessarily constitute a vulnerability, so you'll need to do further testing using the manual techniques outlined above. For more information, see the Suspicious input transformation issue definition.)

    您还可以使用 Backslash Powered Scanner BApp 来识别服务器端注入漏洞。扫描器将输入分类为无聊、有趣或易受攻击。您需要使用上述手动技术来调查有趣的输入。有关详细信息,请参阅反斜杠 《Powered Scanning: Hunting unknown vulnerability classes》白皮书。
    (You can also use the Backslash Powered Scanner BApp to identify server-side injection vulnerabilities. The scanner classifies inputs as boring, interesting, or vulnerable. You'll need to investigate interesting inputs using the manual techniques outlined above. For more information, see the Backslash Powered Scanning: hunting unknown vulnerability classes whitepaper.)

    防止服务器端参数污染
    Preventing server-side parameter pollution

    为防止服务器端参数污染,请使用允许列表来定义不需要编码的字符,并确保所有其他用户输入在包含在服务器端请求中之前都已编码。您还应该确保所有输入都遵循预期的格式和结构。
    (To prevent server-side parameter pollution, use an allowlist to define characters that don't need encoding, and make sure all other user input is encoded before it's included in a server-side request. You should also make sure that all input adheres to the expected format and structure.)

  • -2 赞同
    1 帖子
    284 浏览
    尚无回复
  • 服务器端的漏洞(相关学习)

    技术交流
    0 赞同
    24 帖子
    548 浏览

    实验室:允许绕过登录的 SQL 注入漏洞

    本实验在登录函数中包含一个 SQL 注入漏洞。

    若要解决实验室问题,请执行以用户身份登录应用程序的 SQL 注入攻击。administrator

    使用 Burp Suite 拦截和修改登录请求。 修改参数,为其赋值:usernameadministrator'--

    实验步骤

    目的为以管理员用户登录应用程序
    尝试账号密码为admin。网页显示,Invalid username or password,无效的用户名或密码,故此不知道是用户名还是密码错误。
    2e65ae8e-7059-42f6-9f12-b5fa9b9c680a-image.png
    从实验室说明中查的用户名为administrator
    feb01956-f6b6-4d04-9e09-ed3e83a29a7e-image.png
    在Username中输入any' or 1=1 -- ,密码随便写毕竟会被注释掉
    用any'来闭合参数,or一个为真即可通过,-- 是 sql 的注释语法注释掉后面的密码
    在Username中输入administrator'-- ,密码随便写毕竟会被注释掉
    8173bfd7-1178-4dda-a998-c0865b692ef3-9e674102a5164c4c54a2b2ff9f5b8c1.png
    浏览器连上代理,在登录页面用 bp 抓包,修改其参数
    fa6e5393-4d7e-4839-b647-338761108e41-d619dae3e684645c57a1a468a1b5503.png

  • Spring 集成Milvus报错

    技术交流
    0 赞同
    2 帖子
    276 浏览

    解决办法,排除冲突的依赖

    <dependency> <groupId>io.milvus</groupId> <artifactId>milvus-sdk-java</artifactId> <version>2.4.1</version> <exclusions> <exclusion> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-slf4j-impl</artifactId> </exclusion> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> </exclusion> <exclusion> <groupId>org.apache.hadoop</groupId> <artifactId>hadoop-client</artifactId> </exclusion> </exclusions> </dependency>
  • 全职or兼职的远程工作

    招聘
    0 赞同
    2 帖子
    810 浏览

    你还在为找不到工作而苦恼吗?来,看这里,这里有成千上万的工作,只要你有能力,里面的工作都是你的,你可以兼职,也可以全职,时间自由,只要你想工作了,就进来。。。
    你还为每天上下班时间太长而整体没有精神吗?来,看这里,这里是远程办公,你可以不用挤公交,挤地铁,不用怕塞车;你可以睡到自然醒,元气满满的开始你一天的工作。。。
    你还在为下班的时候老板叫你加班或开会而不爽吗?来,看这里,这里只需要你在规定时间内完成任务即可。。。
    是不是很爽,这里就是云队友远程工作平台,是一个提供远程工作求职,远程用人管理的平台。目前,平台有数十万优质人才提供远程工作服务,也有大量远程全职/兼职的职位。平台包涵技术、运营、设计、产品、HR、翻译等多类目职位,满足企业的远程用人需求和人才的远程工作需求。
    加入我们吧!
    https://www.duiyou360.com/?utm_source=user11
    3d40f5f6-a4d7-4713-ad00-53d1ab59fdae-image.png

  • 文鼎字体iCloudfont下载

    综合交流
    1 赞同
    9 帖子
    5k 浏览

    感谢分享

  • 重编译,发布,打包出错,求助

    Github & Git
    0 赞同
    1 帖子
    452 浏览
    尚无回复
  • 空桶投球

    综合交流
    0 赞同
    1 帖子
    582 浏览
    尚无回复
  • 0 赞同
    1 帖子
    607 浏览
    尚无回复
  • 0 赞同
    1 帖子
    2k 浏览
    尚无回复
  • 求代码

    综合交流
    0 赞同
    1 帖子
    1k 浏览
    尚无回复
  • 0 赞同
    2 帖子
    1k 浏览

    发邮件不需要当事人的密码呀。只需要自己写个代码,然后把代码部署完 在配下API就行

  • 0 赞同
    2 帖子
    2k 浏览

    其实这样的网站依旧可以访问,很多时候只是该网站没有采用一些安全协议而已,本身并无“黑”的目的。不过,害人之心不可有,防人之心不可无,如果您必须访问这样的网站,建议采取额外的安全措施,比如确保您的操作系统和防病毒软件是最新的,避免在该网站上输入敏感信息,不点击不明链接或下载未知文件。同时,也可以考虑使用VPN等工具来增加一层网络安全保护。

  • 0 赞同
    2 帖子
    1k 浏览

    解决办法。wsl 挂载windows的目录有问题,直接在wsl里面建一个目录,然后挂载

    docker run -d -p 18123:8123 -p19000:9000 --name clickhouse-server -v ~/volumes/clickhouse/data:/var/lib/clickhouse/ --ulimit nofile=262144:262144 clickhouse/clickhouse-server 5c3e31d25eefd758715b2e54b7b42e048cc9991d52efa4ea1506269fc55bbf19

    参考
    https://github.com/ClickHouse/ClickHouse/issues/55638

  • 【https】如何让http升级成https

    综合交流
    0 赞同
    2 帖子
    2k 浏览

    个人感觉域名托管到cloudflare也不错,直接成HTTPS

  • 0 赞同
    1 帖子
    1k 浏览
    尚无回复
  • 一篇文章就教你快速理解SSL协议

    综合交流
    0 赞同
    1 帖子
    1k 浏览
    尚无回复