Tag: 安全

iOS：减少漏洞和攻击的安全措施: 简介：iOS平台在硬件和软件上均提供了高级安全功能。它是由Apple设计的，以安全为核心。但是，iOS用户担心为iOS应用程序提供的安全级别。 Micro Focus静态代码分析器可以跟踪这些应用程序的主要威胁，从而确定安全漏洞。开发人员可以通过确定这些漏洞的根本原因，关联它们并确定结果的优先级来安全地进行编码。这是一份快速指南，它分析了一些常见漏洞（称为问题陈述）并提供了克服威胁的快速解决方案。 1. 问题陈述：该应用程序有遭受中间人（MITM）攻击和其他基于网络的攻击的风险。说明：在iOS 9中，Apple引入了应用程序传输安全性（ATS），此安全性功能默认情况下要求使用SSL / TLS对应用程序的所有连接进行加密。它阻止任何应用程序发起的“未保护”连接，其中包括不使用具有最强TLS版本和密码套件的HTTPS的连接。部分或全部禁用ATS可能会使应用程序遭受网络攻击或MitM攻击。统计数据显示，目前应用商店中约有63％的应用使用NSAllowsArbitraryLoads键选择退出ATS，如下所示： NSAllowsArbitraryLoads =真解决方案：如果应用程序的ATS策略将NSAllowsArbitraryLoads设置为YES ，则通过添加所需的豁免和域来修改策略，以便能够将NSAllowsArbitraryLoads设置为NO 。如果没有，您的应用程序迟早会被阻止。使用NSURLSession和NSURLConnection时，默认情况下启用ATS。诸如NSAllowsArbitraryLoads — NSAllowsArbitraryLoadsForMedia — NSAllowsArbitraryLoadsInWebContent — NSExceptionMinimumTLSVersion之类的某些键会触发附加的App Store审查并要求理由。 ATS实施用于安全网络连接的最佳做法，例如TLS 1.2和转发保密性。将来会进行更新以反映Apple的网络最佳做法。 2. 问题陈述： TLS / SSL的弱版本可能具有以下一个或多个属性： –无法抵御MITM攻击 –用于认证和加密的密钥相同 –弱消息身份验证控制 –无法防止TCP连接关闭这些可能使攻击者可以拦截，修改或篡改敏感数据。说明：传输层安全性（TLS）和安全套接字层（SSL）协议提供了一种保护机制，以确保在客户端和Web服务器之间传输的数据的真实性，机密性和完整性。 TLS和SSL都经过了修订，导致定期的版本更新。每个新修订版都旨在解决以前版本中发现的安全漏洞。使用不安全版本的TLS / SSL会削弱数据保护的强度，并且可能使攻击者能够泄露，窃取或修改敏感信息。 […]

减少攻击面和漏洞[SWIFT CSP 3/8]: 这篇文章是一个由八部分组成的系列文章的第三部分，该系列文章帮助企业领导者寻求确保其团队已正确遵守新控制制度的保证。在这篇文章中，我们研究第二个原则：减少攻击面和漏洞。这适用于具有本地SWIFT实现的用户和使用局服务的用户。它旨在最大程度地减少攻击者已知的漏洞的暴露，并防止攻击者使用默认设置来访问您的系统。有什么风险？您的支付基础架构自然具有并且确实需要启动交易的能力。这使其成为希望从您和客户的帐户中窃取金钱的犯罪分子的目标。坚持使用我们先前文章中的银行金库类比-安装金库时，您将确保使用的材料经过适当硬化以保护金库中的物品（例如钢筋混凝土和钢材！）。如果通过沉降出现裂缝，则应确保将其检出并修补。您还要确保未将库门上的组合设置为默认值1234！在成功进行网络攻击的地方，攻击者可以轻松使用已知的漏洞和默认密码来访问操作员PC。控制目标：此原则中的强制控制的目的是确保硬件和软件从其供应商处接收更新，从而阻止攻击者利用已知漏洞或默认设置来破坏系统的机会。此原则中的控件旨在确保您遵循维护技术的过程。这样，通过使攻击者更难使用已知的漏洞和设置来破坏操作员PC和SWIFT基础结构，可以减少成功攻击的可能性。要问的问题：在寻求确保他们已履行此控制的义务时，高级管理人员应考虑以下问题，以使他们对证明和降低风险有信心：我们是否对SWIFT“安全区域”中的所有硬件和软件都有积极的支持安排？ SWIFT安全区内的所有硬件（例如，网络设备，服务器）和软件（例如，操作系统，应用程序）都应在其供应商的支持生命周期内。这样一来，您将收到安全更新，这些更新将减少攻击者使用已知漏洞来破坏您的支付系统的能力。在什么时间范围内将“关键”和“高”安全补丁应用于系统？许多组织将基于风险的方法应用于补丁程序管理。考虑到供应商的重要性，对业务的运营影响以及您可能已经实施的其他补偿性控制。通常，这将在组织的“修补政策”中定义。作为指导，应用评级为“关键”（CVSS-通用漏洞评分系统-分数9.0以上）的安全更新所花费的时间不应超过1个月。 “高”（CVSS得分7.0+）不应超过2个月。我们如何加强操作员PC的操作系统？我们如何加强与SWIFT相关的应用程序？我们如何加强支持基础设施？（例如防火墙，路由器等）在回答这些问题时，您的团队应该能够确认他们已遵循行业标准指南。他们可能会提到CIS，NIST或当地监管机构的要求。他们至少应能够向您确认所有设备上的默认密码均已更改，未使用的系统和用户帐户已被禁用，以及不必要的软件/服务也已被禁用或删除。以下内容仅适用于“架构A”（内部）SWIFT部署：我们如何加密网络上与SWIFT相关的应用程序之间的流量？机器对机器的接口应使用TLS等加密技术来保护。加密应该是“双向”的，这意味着两个应用程序都相互验证身份，并对它们之间的流量进行加密。我们如何加密从操作员PC到SWIFT应用程序的流量？来自运营商PC的用于发起交易的连接也应使用TLS进行加密。通常，这将是“单向的”，这意味着仅验证服务器的身份。对于Web应用程序，用户将在地址栏中看到挂锁。结论通常，为了成功地按照此原则实施控件，您的团队将确定用于提供SWIFT付款服务的硬件和软件。 IT团队将具有强大的补丁程序管理程序，以及时识别，评估和部署来自供应商的更新。他们还将审查SWIFT安全区域中的硬件和软件以一致的方式增强以抵抗攻击的方式。这样，您的团队将使攻击者更难利用已知漏洞并使用默认密码。这将减少攻击者成功破坏您的SWIFT网关和运营商PC的可能性。在本系列的下一篇博客文章中，我们将着眼于物理上保护您的环境。您还可以查看本系列的其余文章。请记住跟随并联系，以便您得到通知，同时，如果您有任何疑问，请随时发表评论，或给我发消息以获取更多信息。

使用Alamofire在iOS上使用证书固定的网络安全: 在当今的现代世界中，我们与移动设备的连接比以往任何时候都多。我们通过应用程序保留和共享我们的数据。但是，当我们在星巴克使用不安全的wifi进行工作时，如果这些敏感数据暴露了怎么办？作为开发人员，我们应注意用户的隐私及其数据。在本文中，我想谈谈SSL，以及我们如何通过SSL固定使我们的应用程序更安全。什么是SSL？ SSL或安全套接字层是一种协议，该协议通过Netscape Communications在1999年设计的网络提供加密的通信。当您使用浏览器检查电子邮件或从Medium阅读文章时，如果在网站上看到“ https”前缀，您可能会假设您使用SSL / TLS进行通信。在SSL连接中，客户端和服务器端都必须具有安全证书，并且它们将在发送数据之前对数据进行加密。只有拥有正确安全证书的人员才能解密这些响应。 SSL如何运作？客户端连接到服务器，并要求服务器标识自己服务器发送其公钥和证书。该证书已由客户端控制（无论是否经验丰富，已被吊销）。如果此证书有效，则客户端将创建一个加密的对称会话密钥，并将其发送到服务器。服务器使用其私钥解密此对称会话密钥，并使用会话密钥将客户端发送到确认（ACK）以启动加密的会话。从现在开始，此会话发送的所有数据将被严格终止。为什么要使用SSL固定？ SSL固定将帮助我们避免中间人攻击。使用已固定到应用程序的证书，我们可以确保我们已连接到正确的服务器。当服务器使用公钥发送其证书时，我们将了解我们不会被某人欺骗。使用Alamofire进行SSL固定：我通常使用Alamofire，我必须说我真的很高兴。 Github上最受好评的项目之一，可以提供完美的帮助。

iOS App安全性-2: 作为开发人员，对我来说下一件大事是数据。我们在哪里保存数据？谁可以阅读？它们是加密的吗？我决定检查Apple的文档，以了解他们对文件使用哪种安全性。因此，如果您像我一样好奇，请查阅《 Apple安全指南》。在文件数据保护中，您将了解它们如何加密所有文件，然后在需要时对其解密。这太酷了。那么可以在我们的应用程序中使用它的功能吗？好吧，为什么不呢！您可能已经在项目设置中看到了“功能”选项卡。如果仔细看，将看到“数据保护”部分。因此，让我们再次检查Apple的文档：数据保护是一种iOS功能，可用于保护应用文件的安全并防止未经授权的访问。当用户设置设备的活动密码时，将自动启用数据保护。您通常可以读写文件，但是系统会在后台对内容进行加密和解密。加密和解密过程是自动的，并且硬件加速。这是非常有用和有趣的。因此，您将有四种保护级别的选择。但是，如果您仔细阅读，它会说解锁手机后文件将被解密。这意味着这项出色的技术可以将我们的数据保存在小偷的手中，但可能并非所有黑客都可以。如果我的手机越狱，当设备解锁时，我可以访问文件和所有内容。我发现的唯一可能的解决方案是由我自己加密数据，以避免黑客访问数据。如果您使用CoreData来保存数据，那么处理一切并不是那么容易。但是我找到了一个可以帮助你的图书馆 project-imas /加密核心数据 v2.0 –使用SQLCipher的iOS Core Data加密SQLite存储– project-imas / encrypted-core-data github.com 但是，如果您像我们一样使用Realm。对您来说可能更容易 https://academy.realm.io/posts/tim-oliver-realm-cocoa-tutorial-on-encryption-with-realm/ 但这还不是全部。通常，在我们的应用程序中，我们使用Userdefault来保存和检索数据。 Userdefault基本上是您的应用程序文件夹/ Library / Preferences /下的plist文件。这意味着在越狱的手机中，我可以访问它并非常轻松地阅读它。因此，请不要将其用作数据库！让我们继续Keychain 。我能想象你在说地狱吗？这肯定是安全的。好，让我们先看看什么是钥匙串。根据苹果的文件： […]

使用Buttercup for Mobile在iOS上自动填写登录表单: Apple的iOS版本12推出了一项神奇的新功能，允许使用用户的凭据自动填写登录表单，这些凭据存储在他们最喜欢的密码管理器中。当出现屏幕键盘时，键盘顶部会显示密码选择，以便于访问。本质上，这意味着可以流畅，有效地访问所有登录详细信息，而无需运行复杂脚本的应用内浏览器来为您执行自动填充。在iOS上不再需要这些功能，这意味着用户可以直接在Safari中停留而不必使用这些自定义浏览器。这项新功能可直接为您提供密码，而无需在手机上或iCloud中显式存储您的详细信息。还有一个选项是点击“钥匙”图标，这会弹出一个菜单，其中包含其他一些选择，例如从当前的密码管理器中选择另一个，或者从iCloud中选择一个：如果您选择在Buttercup中查找其他证书，则可以在保管库中搜索另一个证书：轻击键盘上方的项目或上方屏幕中的搜索结果，将触发使用Buttercup条目中包含的详细信息填写登录表单。

iOS钥匙串中受密码保护的条目: 您将拥有应用程序的名称，而不是“ keychain-sample”。请注意，在这种情况下， SecItemCopyMatching调用是同步的，必须在后台线程上完成以防止主线程阻塞。如果用户输入了错误的密码，那么iOS会自动重新显示提示。在用户输入正确的密码或点击“取消”或超过允许的最大尝试次数（由系统定义的情况下，如果我没有记错的话，为5次）， SecItemCopyMatching调用将不会返回。使用LAContext.evaluateAccessControl 如果我们要手动控制尝试次数，并且还避免长时间运行阻塞调用SecItemCopyMatching则可以使用稍微不同的方法：在这里，我们创建一个LAContext实例，并为它调用带有operation: .useItem evaluateAccessControl operation: .useItem 。这个evaluateAccessControl调用将触发与我们之前相同的UI提示。但是，后续的SecItemCopyMatching调用不会被阻止。同样值得注意的是，由于这个原因， localizedReason参数在此evaluateAccessControl调用中被忽略，并且UI提示与前面的情况完全相同。为SecItemCopyMatching准备数据的关键点是将LAContext实例设置为kSecUseAuthenticationContext密钥的值，并且还为kSecUseAuthenticationUI设置kSecUseAuthenticationUIFail值。在这种情况下，第一次尝试输入错误密码后，我们的loadPassProtected调用将失败，如果要允许第二次尝试，我们将必须手动重复该过程。这样我们就可以控制尝试次数。顺便说一句，如果我们在SecItemCopyMatching调用中不使用kSecUseAuthenticationUIFail ，则系统将以与以前相同的方式自动处理错误的密码。并且SecItemCopyMatching将变得阻塞。自定义用户界面，而不是系统提示现在，如果系统密码提示不适用于我们的应用程序设计怎么办？看来我们可以实现自己的用户界面来输入密码，只需将密码值提供给钥匙串API。为此，我们必须创建一个LAContext实例，并将从用户获得的密码设置LAContext实例。与将条目保存在钥匙串中时的方式相同：在这里，我们还使用了非阻塞的SecItemCopyMatching调用。还应注意，您需要一个真实的设备来测试此代码。它在模拟器中不起作用。我看到有人提到它在关闭密码的真实设备上不起作用，例如： iOS钥匙串– LAContext.setCredential（data，.applicationPassword）在模拟器上返回false 似乎applicationPassword与设备的系统密码结合使用。因此，… stackoverflow.com 但是我的测试表明，至少在iOS 12中，当我关闭设备上的密码时，它可以正常工作。如本文中所述，用于创建和读取受密码保护的条目的示例代码可以在github上的该项目中找到： algrid /钥匙串样本 iOS钥匙串用法示例。通过在GitHub上创建一个帐户来为algrid / keychain-sample开发做出贡献。 github.com 我希望这些信息对提高您的iOS应用程序的安全性很有帮助。如果您发现问题或有任何建议，请告诉我。

iOS App安全性-5: 稍后我们将看到如何使用这些信息。但是由于在本文中，我进入了工具，让我们来看看class_dump。 class_dump的作用：它为类，类别和协议生成声明。在其开发时，它仅用于Objective-C运行时信息。 http://stevenygard.com/projects/class-dump/ 但是有一个支持迅速的回购叉，这很有趣 0xced / class-dump 这是一个命令行实用程序，用于检查存储在Mach-O文件中的Objective-C运行时信息。它产生… github.com 作为示例应用程序，我使用了YahooWeather，我认为它是最漂亮的应用程序之一。如您所见，它基于obj-c，并且您看到所有标头。这足以操纵一个App。我们将使用这些工具继续进行逆向工程。

在iOS应用中管理机密: 几乎所有iOS应用程序都需要私有值，例如API密钥，机密和密码。其中一些可能需要在源代码中使用，以设置第三方SDK或后端API。在构建过程中或使用开发人员工具时可能需要一些秘密，例如与Apple Developer帐户进行通信。将秘密包含到应用程序中的简单方法包括：将值直接放入代码中，将值放入构建脚本中或将其保存在Info.plist文件中。不幸的是，这些方法意味着这些秘密被提交给源代码控制，并且任何对代码有访问权限的人都可以看到。此外，可以从已编译的应用程序中提取添加到应用程序捆绑包中的脚本和plist文件。我们将研究一些更安全的方式来管理iOS项目中的机密，以便从代码中访问它们。值得注意的是，由于应用程序在用户设备上“泛滥成灾”，因此几乎不可能将应用程序中的任何内容100％保密。一个好的方法是针对这种情况实施适当的保护级别，例如，银行应用程序应该比待办事项列表应用程序具有更高的安全级别。本文是对我之前撰写的关于在iOS应用程序中保持Git机密的主题的文章的改进和扩展。出于各种原因，对于开放源代码项目和封闭源代码项目，都必须使秘密不受源代码控制。通过将秘密提交给源代码控制，您将与所有对存储库具有读访问权限的用户（包括将来会访问任何权限的用户）共享这些值。您可能拥有需要访问项目但不一定使用所有机密的用户。用户签出存储库后，他们将获得存储在本地计算机上的所有机密的副本。如果您的源代码控制系统受到威胁，则不仅将获得源代码，还将获得所有密码和其他机密。 Git允许我们包含一个.gitignore文件，在这里我们可以列出应保留的文件（或表达式）。如果我们的应用程序需要这些文件，则每个开发人员只需创建这些文件并添加任何必需的值即可。我们可以在Git中包含这些文件的模板版本，或在文档中提供所需指南，包括在需要时提供秘密的人员的联系方式。大多数iOS开发人员都知道，许多iOS项目使用Cocoapods作为依赖项管理器。 Cocoapods包括一个插件系统，该插件系统可将其进程连接到其中。 cocoapods-keys是可用于安全管理应用程序秘密的此类插件之一。 cocoapods密钥不仅可以将秘密信息排除在项目源之外，还可以将其安全地保存在系统钥匙串中。安装或更新Pod后，会要求开发人员提供每个尚未存储的值的密钥。生成一个Objective-C类，其中包含键的混淆版本及其值。由于此类是通过运行Cocoapods构建的，因此Pods/CocoaPodsKeys目录可以添加到.gitignore 。该插件具有许多优点：它要求为每个密钥提供一个值，而无需记录所需的秘密。这使得每个开发人员都很容易配置他们的项目环境。源文件已生成，因此可以很容易地使其不受源代码控制。机密会在生成的源中加密，以防止从应用程序二进制文件中提取密钥。可以从Swift和Objective-C源码中使用它。通过读取钥匙串，我们可以根据需要访问构建脚本中的秘密。我们可以在使用cocoapods-keys的不同项目之间共享密钥。将cocoapods-keys集成到我们的项目中非常简单，并且首先将插件包含到我们的Podfile 。在下一次运行pod install ，将要求我们输入上面列出的每个键的值。配置完所有密钥后，插件将生成一个源文件，可以在我们的代码中引用该源文件来读取密钥。对于像后端API秘密这样的值，我们可能希望它在调试和发布时有所不同，我们可以同时包含两个密钥，然后在运行时读取另一个密钥。显然，有许多不同的处理方式，具体取决于我们拥有的用例。因此，我们在这里不讨论所有可能的选项，而仅根据应用程序是否在调试配置中构建而着眼于切换。如果您在项目中使用Cocoapods，我建议您使用Cocoapods键来解决其他问题，因为它是一种安全且易于使用的方法。许多项目不使用Cocoapods，或者我们可能不想使用插件，因此我们也可以考虑自己实施解决方案。机密将被传递到构建过程中，在此过程中它们将作为环境变量提供。然后，我们可以读取这些变量并使用它们来生成源文件，该文件将使我们的代码可以访问我们的秘密值。我们可以在不同的环境中使用不同的值 Xcode提供了可以链接到特定构建配置的xcconfig文件，以便加载其中指定的设置。可以为每个构建配置指定一个xcconfig文件，从而使我们可以为每个环境使用不同的值。我们可能希望将我们的应用程序指向发布应用程序的生产API，但将其指向调试应用程序的测试后端。请注意，如果某个特定的应用程序不需要依赖于构建配置的不同值，则可以使用Shell脚本而不是xcconfig文件，并在以后将其源文件输入到我们的最终构建阶段。我们首先创建xcconfig文件的示例版本。如果我们将这些文件放在诸如BuildConfig之类的目录中，它将使它们与其他项目文件分开。 […]

掩盖用户的敏感数据-它是私有的。: 作为应用程序开发人员，我使用Apple的iTunes Connect检查销售情况。当您为应用程序提供背景信息时，它会模糊所有销售数据（非常酷！）他们为什么这样做？好吧，Apple建议您将其作为最佳实践，因为iOS会为您的应用创建快照并将其存储在文件系统的缓存中。您可以通过下载iExplorer自己查看。这仅适用于您在App Store以外（例如通过Xcode）安装的应用。否则它将被隐藏，除非有人越狱了您的手机。您可能会说，嘿，如果有人拥有我的手机并且知道如何越狱……他们可以访问我的应用程序的最新视觉状态在我要担心的事情上并不重要。我明白了但是另一方面，如果某些事情是可以预防的，那么防止它们仍然是一个好主意。这就像决定是否要吃最后一个曲奇，即使您一次坐着吃完了盒子的其余部分。您仍然可以选择不吃最后一个cookie，这样会更好。实际上，安全公司建议在审计过程中从iOS的快照功能中隐藏敏感数据。您会注意到所有银行应用程序都这样做。（请参见顶部的gif。）他们的解决方案有些手。无论您在应用程序中的什么位置，他们都用公司的初始屏幕覆盖了所有内容。我不怪他们。他们可能从Apple的示例中复制了该技术，该示例向您展示了如何使用Objective-C用纯黑视图控制器覆盖所有内容。让我们做得更好。协议DisplaysSensitiveData { func hideSensitiveData（） func showSensitiveData（）//我们弄得一团糟，我们将其清理干净 } 将该协议扔到您要保护的任何视图控制器及其容器视图控制器上。例如，UINavigationController：扩展UINavigationController：DisplaysSensitiveData { func hideSensitiveData（）{ 如果让vc = topViewController为？ DisplaysSensitiveData { vc.hideSensitiveData（） } } func showSensitiveData（）{ 如果让vc = topViewController为？ DisplaysSensitiveData { vc.showSensitiveData（） } } } 最后，挂接到UIApplicationDelegate以便在应用程序后台运行或返回时进行适当的调用。 func […]

iOS上的证书固定技术: 嗨伙计！今天，我们将讨论安全性。为了完全理解此处介绍的这些概念，我需要提供一些有关SSL / TLS如何工作的背景知识以及其他内容。当然，这不是一个深入的探讨，它只是在开始主要主题之前的简单说明，如果您已经知道，没关系，只需退出本部分并转到下一部分。在最后，我们将看到一个如何在iOS项目上进行证书固定的实际示例，让我们开始吧！它是什么？ SSL / TLS确保通过HTTPS（即，基于SSL / TLS的HTTP）对客户端-服务器通信进行透明加密。加密基于公共密钥基础结构（简称PKI）。这是透明的，因为应用程序层对此加密过程一无所知，网络基础结构会处理一切，因为程序员我们只是编写应用程序请求，因此将带有纯文本的标头和正文放在请购单中，而网络基础结构则可以完成所有工作我们。握手在发送任何应用程序数据之前，服务器和客户端就如何加密/解密数据进行协商，此过程称为握手，在下图中，您可以看到有关此过程的简化视图：握手后此时，如果有人尝试检查在数据传输中客户端和服务器之间交换的消息，那么任何内容都不会被人类读取，所有流量在传输过程中都会被加密，即，仅从客户端和服务器的角度来解密。证书验证过程在握手过程中，服务器将提供数字证书，并且客户端需要基于预定义的信任证书颁发机构列表（也称为受信任的根CA存储）信任证书颁发者。在安全连接上，如果所提供的证书是由未知的颁发者颁发的，则通常浏览器会显示警告⚠️，供用户决定是否必须继续进行连接。默认情况下，在连接中断的情况下，应用程序上的此行为是不同的。您有可能在设备上将自签名证书设置为受信任，在这种情况下，客户端将在后续连接中信任此证书。中间人袭击如果您的连接不是通过连接到原始服务器，而是通过另一台伪装成原始服务器的服务器，将会发生什么情况？从Imperva Incapsula网站上看到有关中间人攻击的简要描述。中间人（MITM）攻击是一个通用术语，指的是犯罪者将自己置于用户与应用程序之间的对话中-进行窃听或假冒其中一方，使其看起来像是正常的信息交换进展中。在这种情况下，攻击者可以看到所有流量，并且可以捕获所有信息。它是什么？通过以上介绍的背景，我们可以更好地了解什么是证书固定。众所周知，在握手过程中，服务器将出示必须由客户端信任或不信任的证书。证书固定技术在于将目标的服务器证书保存在应用程序捆绑包中，并且仅对此信任。我们的例子让我们看一个实际的源代码，为此，我创建了一个在Heroku和一个客户端iOS项目上发布的存根身份验证剩余服务。在发布本文档时，生成的证书尚未过期并且服务已启动。当然，随着时间的推移，我无法保证，但是如果您正确地理解了这一概念，则可以更改证书和主机名以成功获得自己的服务。在我们的示例中，我们将使用post方法访问以下URL https://floating-stream-25740.herokuapp.com/authentication/login来提交如下所示的请求： POST /身份验证/登录HTTP / 1.1 主持人：floating-stream-25740.herokuapp.com 内容类型：application / x-www-form-urlencoded 缓存控制：无缓存 id = user＆password = pass 通知的ID或密码无关紧要，它仅用于测试。 […]