Questions tagged «security»

我听说过的大多数安全威胁是由于软件中的错误引起的（例如，未正确检查所有输入的完整性，堆栈溢出等）。因此，如果我们排除所有社交黑客攻击，是否都是由于漏洞引起的安全威胁？换句话说，如果没有错误，是否就不会有安全威胁（再次，排除诸如公开密码之类的人类错误）？还是可以通过非漏洞引起的方式利用系统？

13 security  bug  hacking 

我在公司的一个面向公众的站点中发现了一个重大安全漏洞。这是我们第一个从Intranet网站转换而来的面向公众的网站。我把这个问题交给了我的老板，他们基本上不予理,，说要重新构造站点以使其安全，需要大量的工作。 这确实让我感到困扰，我已经考虑过利用该漏洞来表明如果真正的黑客入侵，可能会发生的后果。这可能不是最好的主意，因为如果没有更糟的效果，这些效果可能会使我丧命。 我可以做些什么来向管理层表明情况的严重性？

13 security  ethics 

我对SQL注入攻击的所有了解似乎都表明，参数化查询（尤其是存储过程中的参数化查询）是防范此类攻击的唯一方法。在我工作的时候（回到黑暗时代），存储过程被认为是一种不好的做法，主要是因为它们的可维护性较差。可测试性较低；高度耦合；并将系统锁定在一个供应商中；（此问题涵盖其他一些原因）。 尽管在我工作时，项目实际上并没有意识到这种攻击的可能性。采用了各种规则来保护数据库免受各种损坏。这些规则可以概括为： 没有客户端/应用程序可以直接访问数据库表。 对所有表的所有访问都是通过视图进行的（对基本表的所有更新都是通过触发器进行的）。 所有数据项都有指定的域。 不允许任何数据项为空-这意味着DBA有时会磨牙。但被执行了。 角色和权限已适当设置-例如，受限制的角色仅授予视图更改数据的权利。 那么，这样的一组（强制）规则（尽管不一定是特定的一组）是否可以替代参数化查询，以防止SQL注入攻击？如果没有，为什么不呢？可以通过（仅）数据库特定措施来保护数据库免受此类攻击吗？ 编辑 鉴于收到的初步答复，对该问题的重视程度略有变化。基本问题不变。 编辑2 依赖参数化查询的方法似乎只是防御系统攻击的外围步骤。在我看来，更基本的防御措施既可取，又可能使对此类查询的依赖变得不必要或不太关键，甚至可以专门防御注入攻击。 我的问题中隐含的方法基于“加固”数据库，我不知道它是否是可行的选择。进一步的研究表明存在这样的方法。我发现以下来源提供了一些指向这种方法的指针： http://database-programmer.blogspot.com http://thehelsinkideclaration.blogspot.com 我从这些来源获得的主要特征是： 广泛的数据字典，与广泛的安全数据字典相结合 从数据字典生成触发器，查询和约束 最小化代码并最大化数据 尽管我到目前为止所获得的答案非常有用，并指出了忽略参数化查询所带来的困难，但最终它们并没有回答我的原始问题（现在以粗体强调）。

13 design  security  sql  sql-injection 

按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 6年前关闭。 我正在考虑限制选择不安全密码的用户的权限（密码的不安全性由长度，使用的字符类型（大/小写，数字，符号等）决定，是否可以使用）。 （位于彩虹表中）以限制帐户遭到破坏后所造成的损失。 我还没有这个想法的申请，但是说我正在写一个论坛之类的东西：使用1234作为密码的用户可能必须在发布前填写验证码，否则将受到诸如此类的严格反垃圾邮件措施的约束。作为超时或贝叶斯过滤器拒绝其内容。如果此论坛是非常分层的，允许“提升”主持人或通过某种方式进行的其他活动，这将阻止他们完全获得特权或告诉他们他们具有特权，但不允许他们在不进行任何更改的情况下行使其特权。密码。 当然，这不是唯一的安全措施，但是它可以很好地替代其他良好的安全做法。 你怎么看？这是否只是做的太过分，将注意力从更重要的安全实践上转移了下来，还是限制风险并鼓励用户使用更安全的密码的一种好方法（并希望说服您正在使用良好的安全实践的人们）？

13 security  passwords  authorization  risk  permissions 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 6年前关闭。 当今最流行的应用程序要求通过电子邮件激活帐户。我从未使用自己开发的应用程序来做到这一点，所以我是否缺少一些关键的安全功能？ 通过电子邮件激活，我的意思是当您注册到站点时，他们会向您发送一封电子邮件，其中包含您必须在激活帐户之前单击的链接。

13 security  email 

我们正在开发一个新项目，我们是两个主要开发人员，并且在如何使用令牌保护服务器与客户端之间的通信方面处于十字路口。 第一个建议：（一次性令牌AKA静态令牌） 客户端通过向api发送用户名和密码以及current_time（此变量也将保存在服务器的数据库和客户端中）来请求主令牌，服务器解释输入并呈现哈希令牌（例如： 58f52c075aca5d3e07869598c4d66648）将其保存在数据库中，并将其返回给客户端。 客户端现在保存主令牌，并使用主令牌+身份验证请求中发送的current_time变量创建新的哈希令牌（让我们将此新令牌称为main_token），服务器也将执行相同操作，并使用相同的算法创建相同的令牌。 客户端每次查询服务器API时，都会将main_token发送到服务器，现在服务器会将其中生成的令牌与客户端发送的main_token进行比较，如果匹配，则表示用户是真实的 第二个建议：（动态令牌） 客户端生成两个随机键（$ key1 = rand（10000,90000）; $ key2 = rand（10000,90000）;）在API上的每个请求上，客户端都会使用查询类型创建一个哈希，而两个键分别为一个复杂的算法，然后将这两个密钥+哈希发送到服务器 服务器使用与客户端相同的算法，创建一个哈希，然后将其与客户端发送的哈希进行比较，如果匹配，则服务器继续处理查询 现在的问题是，哪一种是用于保护API请求的最合理，最安全的方法？

13 security  api 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 与硬件的密切联系存在许多安全风险，这与使用高级编程语言经过测试和验证的API形成对比。与诸如Java之类的语言相比，用C引起缓冲区溢出要容易得多。 每个C程序员都应该意识到哪些风险或漏洞（例如缓冲区溢出）（与C程序员相关的IE漏洞）？这些可能导致什么问题？如何避免它们，以及导致这些错误在程序中发生的常见错误是什么？

13 c  security  low-level  vulnerabilities 

我想实现一个更强大的身份验证服务，这jwt是我要做的事情的很大一部分，而且我了解如何编写代码，但是在理解保留iss与aud声明之间的区别时遇到了一些麻烦。我知道，一个定义了颁发令牌的服务器，而一个则引用了打算使用的应用程序。但是我的理解是，我的听众和发行人是同一件事，myserver.com就是发行令牌，以便以后的人们myserver.com可以得到授权和认证。我想我看不到两种说法之间的区别，尽管我知道有一种。 有一篇很好的文章写在msdn 关于所有保留的索赔，这是我最困惑的地方，因为他们的发行人和受众完全不同。

13 security  authentication  authorization  jwt 

大约十年来，我一直在使用SQL Server数据存储来处理各种内部桌面客户端应用程序。我很少启动这些项目-大多数是接管工作。 似乎到处都是的一件事是，该应用程序使用了一个单一的全局SQL Server用户帐户，该帐户向普通数据库授予了该帐户的权限，是的，在某些幼稚的情况下，它使用了该sa用户帐户，我通常尝试在可能的情况下进行修复。 您不能真正有效地隐藏应用程序用来访问数据库的用户名和密码。它们通常存储在ini或config文件中，或者可能烘焙到可执行文件本身中。在所有情况下，如果进行一点挖掘，它们对于用户都是可见的。在一种情况下，我们实际上使用了一个config文件但对其进行了加密，但是当然加密密钥必须存储在可执行文件中（我们并非天真地限制了它的局限性，但是它确实有效地阻止了人们回避那些精明的人查看config文件）。 所有这些系统都在应用程序中内置了一个用户身份验证系统，但是当然它们都是通过应用程序本身进行管理的，这意味着用户信息存储在数据库中。该应用程序根据访问级别限制了您可以执行的操作，但是如果您仅可以连接到数据库并运行即席查询，那就太麻烦了。 我很想知道其他系统可以解决这个问题。这是我所知道的选项： 使用SQL Server的安全性机制维护用户和角色列表，并使桌面应用程序通过T-SQL查询添加和删除用户。 创建直接在服务器上运行的某种Web服务并将身份验证逻辑放在其中，而不是直接连接到数据库。使每个请求都进行安全验证。 第一个选项有些丑陋，因为您要将用户与数据库分开，因此用户不再是一流的实体，并且不能使用外键关系等来引用它们。 第二个似乎是一个主要的性能问题，需要大量额外的工作，而且您不能像NHibernate（我认为）那样容易地使用ORM映射器。 这个事情谁有经验？最佳做法？ 编辑 再想想，SQL Server身份验证能否真正解决此问题？例如，如果您的用户必须能够插入和更新时间表记录，以便您可以编辑时间表，则SQL Server无法禁止访问时间表明细表中的其他行，这意味着您也可以读写其他人的时间表。

12 database  security 

作为程序的创建者，您可能比其他任何人都更容易意识到安全漏洞和潜在的黑客攻击。如果您知道编写的系统中的漏洞，是否必须在发布之前添加增加安全性的标志，还是应该逐案评估以确定安全漏洞的严重性？

12 security  release 

今天，我的经理向我提出了一个问题，问我关于什么是可以接受的Web表单应用程序身份验证设计的想法，特别是对于许多流行的浏览器的性质而言，“典型用户名”密码登录字段“记住密码” 。 我在想出一个我认为可以接受的答案时遇到了麻烦。鉴于Sony令人尴尬的安全漏洞，即使存储在人身上的数据敏感度较低，我也确实要小心。我们不存储社会安全号码，甚至不存储地址，但是我们存储电话号码，电子邮件地址和访客的照片。 他担心用户可以简单地在公共终端上记住密码，然后有人可以简单地跳到该终端上并以未经授权的方式开始查看或修改数据。但是，我相当确定，至少在Windows工作站上，浏览器不会跨Windows用户帐户“记住密码”。 除此之外，我正在服务器端实现一种单向密码加密（将加密的密码存储在数据库中，在服务器上加密用户提供的密码，与数据库中的加密字符串进行比较）。目前尚无合并SSL加密的计划，但这仍然是一个选择。 这种方法是否存在主要的安全缺陷？您有更好的建议吗？

12 web-applications  security  browser  authentication 

我正在设置一个新的RESTful Web服务，我需要提供一个基于角色的访问控制模型。我需要创建一个体系结构，该体系结构将允许用户提供用户名和密码来访问服务，然后根据角色限制他们如何使用服务（可以使用哪些服务，读取与读取/写入等）。分配给该用户。 我环顾了其他问题，发现了我想要的东西。例如，关于如何处理将凭证传递到REST服务的静态身份验证，最佳实践等方面，存在许多精彩的讨论。关于创建网站时程序员应了解的知识（每个开发人员在构建公共网站之前应了解的知识），也有一些很好的指导。 但是我找不到关于实现这些解决方案的软件体系结构的最佳实践和模式的好文章，文章和书。 特别： 用户信息和访问权限应如何存储？（数据模型，位置，格式） 有哪些好的设计模式可以表示和跟踪服务器中的这些模式？（内存中的会话，每次数据库查找等） 在代码库中以哪种安全方式将这些权利映射到服务的良好模式是什么？ 哪些架构选择可以帮助保持系统更安全和可靠？ 人们从战es中学到了什么？ 我正在寻找针对任何特定技术之外的软件体系结构的设计模式和建议。 （如果技术很重要，我计划使用python，twisted和postgresql数据库来实现）

12 web-development  design-patterns  security  web-services  rest 

当将盐值添加到哈希值中（例如无法以纯文本形式存储的密码）时，获得盐值的最佳位置是什么？对于上下文，让我们假设这是网页登录时的密码。

12 security  hashing 

使用电子邮件进行注册登录比使用用户名识别用户更好吗？

12 security  user-interface  front-end 

如果密码是散列存储的，那么如果您尝试重置密码，计算机将如何知道您的密码与上一个密码相似？由于一个密码是散列的，并且无法逆转，因此这两个密码不会完全不同吗？

11 database  security  hashing  passwords