❶ Web应用 密码复杂度设置
Web应用密码复杂度设置至少包含两种字符的组合，至少一个小写字母。
默认设置了密码安全策略，但用户可取消，建议用户启用该策略：密码长度为8到128个字符。
❷ web.py怎样安全地传递密码
保护密码最好的的方式就是使用带盐的密码hash(salted password hashing).对密码进行hash操作是一件很简单的事情，但是很多人都犯了错。接下来我希望可以详细的阐述如何恰当的对密码进行hash，以及为什么要这样做。
重要提醒
如果你打算自己写一段代码来进行密码hash，那么赶紧停下吧。这样太容易犯错了。这个提醒适用于每一个人，不要自己写密码的hash算法 ！关于保存密码的问题已经有了成熟的方案，那就是使用phpass或者本文提供的源码。
什么是hash
hash("hello") =
hash("hbllo") =
hash("waltz") =
Hash算法是一种单向的函数。它可以把任意数量的数据转换成固定长度的“指纹”，这个过程是不可逆的。而且只要输入发生改变，哪怕只有一个bit，输出的hash值也会有很大不同。这种特性恰好合适用来用来保存密码。因为我们希望使用一种不可逆的算法来加密保存的密码，同时又需要在用户登陆的时候验证密码是否正确。
在一个使用hash的账号系统中，用户注册和认证的大致流程如下：
1, 用户创建自己的账号
2, 用户密码经过hash操作之后存储在数据库中。没有任何明文的密码存储在服务器的硬盘上。
3, 用户登陆的时候，将用户输入的密码进行hash操作后与数据库里保存的密码hash值进行对比。
4, 如果hash值完全一样，则认为用户输入的密码是正确的。否则就认为用户输入了无效的密码。
5, 每次用户尝试登陆的时候就重复步骤3和步骤4。
在步骤4的时候不要告诉用户是账号还是密码错了。只需要显示一个通用的提示，比如账号或密码不正确就可以了。这样可以防止攻击者枚举有效的用户名。
还需要注意的是用来保护密码的hash函数跟数据结构课上见过的hash函数不完全一样。比如实现hash表的hash函数设计的目的是快速，但是不够安全。只有加密hash函数(cryptographic hash functions)可以用来进行密码的hash。这样的函数有SHA256, SHA512, RipeMD, WHIRLPOOL等。
一个常见的观念就是密码经过hash之后存储就安全了。这显然是不正确的。有很多方式可以快速的从hash恢复明文的密码。还记得那些md5破解网站吧，只需要提交一个hash，不到一秒钟就能知道结果。显然，单纯的对密码进行hash还是远远达不到我们的安全需求。下一部分先讨论一下破解密码hash，获取明文常见的手段。
如何破解hash
字典和暴力破解攻击(Dictionary and Brute Force Attacks)
最常见的破解hash手段就是猜测密码。然后对每一个可能的密码进行hash，对比需要破解的hash和猜测的密码hash值，如果两个值一样，那么之前猜测的密码就是正确的密码明文。猜测密码攻击常用的方式就是字典攻击和暴力攻击。
Dictionary Attack
Trying apple : failed
Trying blueberry : failed
Trying justinbeiber : failed
...
Trying letmein : failed
Trying s3cr3t : success!
字典攻击是将常用的密码，单词，短语和其他可能用来做密码的字符串放到一个文件中，然后对文件中的每一个词进行hash，将这些hash与需要破解的密码hash比较。这种方式的成功率取决于密码字典的大小以及字典的是否合适。
Brute Force Attack
Trying aaaa : failed
Trying aaab : failed
Trying aaac : failed
...
Trying acdb : failed
Trying acdc : success!
暴力攻击就是对于给定的密码长度，尝试每一种可能的字符组合。这种方式需要花费大量的计算机时间。但是理论上只要时间足够，最后密码一定能够破解出来。只是如果密码太长，破解花费的时间就会大到无法承受。
目前没有方式可以阻止字典攻击和暴力攻击。只能想办法让它们变的低效。如果你的密码hash系统设计的是安全的，那么破解hash唯一的方式就是进行字典或者暴力攻击了。
查表破解(Lookup Tables)
对于特定的hash类型，如果需要破解大量hash的话，查表是一种非常有效而且快速的方式。它的理念就是预先计算(pre-compute)出密码字典中每一个密码的hash。然后把hash和对应的密码保存在一个表里。一个设计良好的查询表结构，即使存储了数十亿个hash，每秒钟仍然可以查询成百上千个hash。
如果你想感受下查表破解hash的话可以尝试一下在CraskStation上破解下下面的sha256 hash。
反向查表破解(Reverse Lookup Tables)
Searching for hash(apple) in users' hash list... : Matches [alice3, 0bob0, charles8]
Searching for hash(blueberry) in users' hash list... : Matches [usr10101, timmy, john91]
Searching for hash(letmein) in users' hash list... : Matches [wilson10, dragonslayerX, joe1984]
Searching for hash(s3cr3t) in users' hash list... : Matches [bruce19, knuth1337, john87]
Searching for hash(z@29hjja) in users' hash list... : No users used this password
这种方式可以让攻击者不预先计算一个查询表的情况下同时对大量hash进行字典和暴力破解攻击。
首先，攻击者会根据获取到的数据库数据制作一个用户名和对应的hash表。然后将常见的字典密码进行hash之后，跟这个表的hash进行对比，就可以知道用哪些用户使用了这个密码。这种攻击方式很有效果，因为通常情况下很多用户都会有使用相同的密码。
彩虹表 (Rainbow Tables)
彩虹表是一种使用空间换取时间的技术。跟查表破解很相似。只是它牺牲了一些破解时间来达到更小的存储空间的目的。因为彩虹表使用的存储空间更小，所以单位空间就可以存储更多的hash。彩虹表已经能够破解8位长度的任意md5hash。彩虹表具体的原理可以参考http://www.project-rainbowcrack.com/
下一章节我们会讨论一种叫做“盐”(salting)的技术。通过这种技术可以让查表和彩虹表的方式无法破解hash。
加盐(Adding Salt)
hash("hello") =
hash("hello" + "QxLUF1bgIAdeQX") =
hash("hello" + "bv5PehSMfV11Cd") =
hash("hello" + "YYLmfY6IehjZMQ") =
查表和彩虹表的方式之所以有效是因为每一个密码的都是通过同样的方式来进行hash的。如果两个用户使用了同样的密码，那么一定他们的密码hash也一定相同。我们可以通过让每一个hash随机化，同一个密码hash两次，得到的不同的hash来避免这种攻击。
具体的操作就是给密码加一个随即的前缀或者后缀，然后再进行hash。这个随即的后缀或者前缀成为“盐”。正如上面给出的例子一样，通过加盐，相同的密码每次hash都是完全不一样的字符串了。检查用户输入的密码是否正确的时候，我们也还需要这个盐，所以盐一般都是跟hash一起保存在数据库里，或者作为hash字符串的一部分。
盐不需要保密，只要盐是随机的话，查表，彩虹表都会失效。因为攻击者无法事先知道盐是什么，也就没有办法预先计算出查询表和彩虹表。如果每个用户都是使用了不同的盐，那么反向查表攻击也没法成功。
下一节，我们会介绍一些盐的常见的错误实现。
错误的方式：短的盐和盐的复用
最常见的错误实现就是一个盐在多个hash中使用或者使用的盐很短。
盐的复用(Salt Reuse)
不管是将盐硬编码在程序里还是随机一次生成的，在每一个密码hash里使用相同的盐会使这种防御方法失效。因为相同的密码hash两次得到的结果还是相同的。攻击者就可以使用反向查表的方式进行字典和暴力攻击。只要在对字典中每一个密码进行hash之前加上这个固定的盐就可以了。如果是流行的程序的使用了硬编码的盐，那么也可能出现针对这种程序的这个盐的查询表和彩虹表，从而实现快速破解hash。
用户每次创建或者修改密码一定要使用一个新的随机的盐
短的盐
如果盐的位数太短的话，攻击者也可以预先制作针对所有可能的盐的查询表。比如，3位ASCII字符的盐，一共有95x95x95 = 857,375种可能性。看起来好像很多。假如每一个盐制作一个1MB的包含常见密码的查询表，857,375个盐才是837GB。现在买个1TB的硬盘都只要几百块而已。
基于同样的理由，千万不要用用户名做为盐。虽然对于每一个用户来说用户名可能是不同的，但是用户名是可预测的，并不是完全随机的。攻击者完全可以用常见的用户名作为盐来制作查询表和彩虹表破解hash。
根据一些经验得出来的规则就是盐的大小要跟hash函数的输出一致。比如，SHA256的输出是256bits(32bytes),盐的长度也应该是32个字节的随机数据。
错误的方式：双重hash和古怪的hash函数
这一节讨论另外一个常见的hash密码的误解:古怪的hash算法组合。人们可能解决的将不同的hash函数组合在一起用可以让数据更安全。但实际上，这种方式带来的效果很微小。反而可能带来一些互通性的问题，甚至有时候会让hash更加的不安全。本文一开始就提到过，永远不要尝试自己写hash算法，要使用专家们设计的标准算法。有些人会觉得通过使用多个hash函数可以降低计算hash的速度，从而增加破解的难度。通过减慢hash计算速度来防御攻击有更好的方法，这个下文会详细介绍。
下面是一些网上找到的古怪的hash函数组合的样例。
md5(sha1(password))
md5(md5(salt) + md5(password))
sha1(sha1(password))
sha1(str_rot13(password + salt))
md5(sha1(md5(md5(password) + sha1(password)) + md5(password)))
不要使用他们！
注意：这部分的内容其实是存在争议的！我收到过大量邮件说组合hash函数是有意义的。因为如果攻击者不知道我们用了哪个函数，就不可能事先计算出彩虹表，并且组合hash函数需要更多的计算时间。
攻击者如果不知道hash算法的话自然是无法破解hash的。但是考虑到Kerckhoffs’s principle,攻击者通常都是能够接触到源码的(尤其是免费软件和开源软件)。通过一些目标系统的密码–hash对应关系来逆向出算法也不是非常困难。
如果你想使用一个标准的”古怪”的hash函数，比如HMAC，是可以的。但是如果你的目的是想减慢hash的计算速度，那么可以读一下后面讨论的慢速hash函数部分。基于上面讨论的因素，最好的做法是使用标准的经过严格测试的hash算法。
hash碰撞(Hash Collisions)
因为hash函数是将任意数量的数据映射成一个固定长度的字符串，所以一定存在不同的输入经过hash之后变成相同的字符串的情况。加密hash函数(Cryptographic hash function)在设计的时候希望使这种碰撞攻击实现起来成本难以置信的高。但时不时的就有密码学家发现快速实现hash碰撞的方法。最近的一个例子就是MD5，它的碰撞攻击已经实现了。
碰撞攻击是找到另外一个跟原密码不一样，但是具有相同hash的字符串。但是，即使在相对弱的hash算法，比如MD5,要实现碰撞攻击也需要大量的算力(computing power),所以在实际使用中偶然出现hash碰撞的情况几乎不太可能。一个使用加盐MD5的密码hash在实际使用中跟使用其他算法比如SHA256一样安全。不过如果可以的话，使用更安全的hash函数，比如SHA256, SHA512, RipeMD, WHIRLPOOL等是更好的选择。
正确的方式：如何恰当的进行hash
这部分会详细讨论如何恰当的进行密码hash。第一个章节是最基础的，这章节的内容是必须的。后面一个章节是阐述如何继续增强安全性，让hash破解变得异常困难。
基础：使用加盐hash
我们已经知道恶意黑客可以通过查表和彩虹表的方式快速的获得hash对应的明文密码，我们也知道了通过使用随机的盐可以解决这个问题。但是我们怎么生成盐，怎么在hash的过程中使用盐呢？
盐要使用密码学上可靠安全的伪随机数生成器(Cryptographically Secure Pseudo-Random Number Generator (CSPRNG))来产生。CSPRNG跟普通的伪随机数生成器比如C语言中的rand(),有很大不同。正如它的名字说明的那样，CSPRNG提供一个高标准的随机数，是完全无法预测的。我们不希望我们的盐能够被预测到，所以一定要使用CSPRNG。
❸ 如何实现一个安全的Web登陆
对于 Web 应用程序，安全登录是很重要的。但是目前大多数 Web 系统在发送登录密码时是发送的明文，这样很容易被入侵者监听到密码。当然，通过 SSL
来实现安全连接是个不错的方法，但是很多情况下我们没办法将服务器设置为带有 SSL 的 Web 服务器。因此如果在登录系统中加入安全登录机制，则可以在没有 SSL
的 Web 服务器上实现安全登录。
要实现安全登录，可以采用下面三种方法，一种基于非对称加密算法，一种基于对称加密算法，最后一种基于散列算法。
非对称加密算法中，目前最常用的是 RSA 算法和
ECC(椭圆曲线加密)算法。要采用非对称加密算法实现安全登录的话，首先需要在客户端向服务器端请求登录页面时，服务器生成公钥和私钥，然后将公钥随登录页面一起传递给客户端浏览器，当用户输入完用户名密码点击登录时，登录页面中的
JavaScript
调用非对称加密算法对用户名和密码用用公钥进行加密。然后再提交到服务器端，服务器端利用私钥进行解密，再跟数据库中的用户名密码进行比较，如果一致，则登录成功，否则登录失败。
对称加密算法比非对称加密算法要快得多，但是对称加密算法需要数据发送方和接受方共用一个密钥，密钥是不能通过不安全的网络直接传递的，否则密钥和加密以后的数据如果同时监听到的话，入侵者就可以直接利用监听到的密钥来对加密后的信息进行解密了。
如何用 hmac
算法实现安全登录。首先在客户端向服务器端请求登录页面时，服务器端生成一个随机字符串，连同登录页面一同发送给客户端浏览器，当用户输入完用户名密码后，将密码采用
MD5 或者 SHA1 来生成散列值作为密钥，服务器端发送来的随机字符串作为消息数据，进行 hmac
运算。然后将结果提交给服务器。之所以要对用户输入的密码进行散列后再作为密钥，而不是直接作为密钥，是为了保证密钥足够长，而又不会太长。服务器端接受到客户端提交的数据后，将保存在服务器端的随机字符串和用户密码进行相同的运算，然后进行比较，如果结果一致，则认为登录成功，否则登录失败。当然如果不用
hmac 算法，直接将密码和服务器端生成的随机数合并以后再做 MD5 或者 SHA1，应该也是可以的。
这里客户端每次请求时服务器端发送的随机字符串都是不同的，因此即使入侵者监听到了这个随机字符串和加密后的提交的数据，它也无法再次提交相同的数据通过验证。而且通过监听到的数据也无法计算出密钥，所以也就无法伪造登录信息了。
对称和非对称加密算法不仅适用于登录验证，还适合用于最初的密码设置和以后密码修改的过程中，而散列算法仅适用于登录验证。但是散列算法要比对称和非对称加密算法效率高。
❹ 用Web上Q安全吗密码会不会被偷
官方答复——
安全机制是这次作为首要因素考虑的，为vhttp协议传输，所以协议加密都重新加密做了，消息加密，本地加密，密码安全都做了保障。
建议用360安全浏览器~~
❺ Web应用常见的安全漏洞有哪些
Web应用常见的安全漏洞：
1、SQL注入
注入是一个安全漏洞，允许攻击者通过操纵用户提供的数据来更改后端SQL语句。当用户输入作为命令或查询的一部分被发送到解释器并且欺骗解释器执行非预期的命令并且允许访问未授权的数据时，发生注入。
2、跨站脚本攻击 （XSS）
XSS漏洞针对嵌入在客户端（即用户浏览器而不是服务器端）的页面中嵌入的脚本。当应用程序获取不受信任的数据并将其发送到Web浏览器而未经适当验证时，可能会出现这些缺陷。
3、跨站点请求伪造
CSRF攻击是指恶意网站，电子邮件或程序导致用户的浏览器在用户当前已对其进行身份验证的受信任站点上执行不需要的操作时发生的攻击。
4、无法限制URL访问
Web应用程序在呈现受保护的链接和按钮之前检查URL访问权限 每次访问这些页面时，应用程序都需要执行类似的访问控制检查。通过智能猜测，攻击者可以访问权限页面。攻击者可以访问敏感页面，调用函数和查看机密信息。
5、不安全的加密存储
不安全的加密存储是一种常见的漏洞，在敏感数据未安全存储时存在。用户凭据，配置文件信息，健康详细信息，信用卡信息等属于网站上的敏感数据信息。
(5)Web密码安全扩展阅读
web应用漏洞发生的市场背景：
由于Web服务器提供了几种不同的方式将请求转发给应用服务器，并将修改过的或新的网页发回给最终用户，这使得非法闯入网络变得更加容易。
许多程序员不知道如何开发安全的应用程序。他们的经验也许是开发独立应用程序或Intranet Web应用程序，这些应用程序没有考虑到在安全缺陷被利用时可能会出现灾难性后果。
许多Web应用程序容易受到通过服务器、应用程序和内部已开发的代码进行的攻击。这些攻击行动直接通过了周边防火墙安全措施，因为端口80或443（SSL，安全套接字协议层）必须开放，以便让应用程序正常运行。
❻ 如何保证Web服务器安全
不但企业的门户网站被篡改、资料被窃取，而且还成为了病毒与木马的传播者。有些Web管理员采取了一些措施，虽然可以保证门户网站的主页不被篡改，但是却很难避免自己的网站被当作肉鸡，来传播病毒、恶意插件、木马等等。笔者认为，这很大一部分原因是管理员在Web安全防护上太被动。他们只是被动的防御。为了彻底提高Web服务器的安全，笔者认为，Web安全要主动出击。具体的来说，需要做到如下几点。一、在代码编写时就要进行漏洞测试 现在的企业网站做的越来越复杂、功能越来越强。不过这些都不是凭空而来的，是通过代码堆积起来的。如果这个代码只供企业内部使用，那么不会带来多大的安全隐患。但是如果放在互联网上使用的话，则这些为实现特定功能的代码就有可能成为攻击者的目标。笔者举一个简单的例子。在网页中可以嵌入SQL代码。而攻击者就可以利用这些SQL代码来发动攻击，来获取管理员的密码等等破坏性的动作。有时候访问某些网站还需要有某些特定的控件。用户在安装这些控件时，其实就有可能在安装一个木马(这可能访问者与被访问者都没有意识到)。 为此在为网站某个特定功能编写代码时，就要主动出击。从编码的设计到编写、到测试，都需要认识到是否存在着安全的漏洞。笔者在日常过程中，在这方面对于员工提出了很高的要求。各个员工必须对自己所开发的功能负责。至少现在已知的病毒、木马不能够在你所开发的插件中有机可乘。通过这层层把关，就可以提高代码编写的安全性。二、对Web服务器进行持续的监控 冰冻三尺、非一日之寒。这就好像人生病一样，都有一个过程。病毒、木马等等在攻击Web服务器时，也需要一个过程。或者说，在攻击取得成功之前，他们会有一些试探性的动作。如对于一个采取了一定安全措施的Web服务器，从攻击开始到取得成果，至少要有半天的时间。如果Web管理员对服务器进行了全天候的监控。在发现有异常行为时，及早的采取措施，将病毒与木马阻挡在门户之外。这种主动出击的方式，就可以大大的提高Web服务器的安全性。 笔者现在维护的Web服务器有好几十个。现在专门有一个小组，来全天候的监控服务器的访问。平均每分钟都可以监测到一些试探性的攻击行为。其中99%以上的攻击行为，由于服务器已经采取了对应的安全措施，都无功而返。不过每天仍然会遇到一些攻击行为。这些攻击行为可能是针对新的漏洞，或者采取了新的攻击方式。在服务器上原先没有采取对应的安全措施。如果没有及时的发现这种行为，那么他们就很有可能最终实现他们的非法目的。相反，现在及早的发现了他们的攻击手段，那么我们就可以在他们采取进一步行动之前，就在服务器上关掉这扇门，补上这个漏洞。 笔者在这里也建议，企业用户在选择互联网Web服务器提供商的时候，除了考虑性能等因素之外，还要评估服务提供商能否提供全天候的监控机制。在Web安全上主动出击，及时发现攻击者的攻击行为。在他们采取进一步攻击措施之前，就他们消除在萌芽状态。 三、设置蜜罐，将攻击者引向错误的方向 在军队中，有时候会给军人一些伪装，让敌人分不清真伪。其实在跟病毒、木马打交道时，本身就是一场无硝烟的战争。为此对于Web服务器采取一些伪装，也能够将攻击者引向错误的方向。等到供给者发现自己的目标错误时，管理员已经锁定了攻击者，从而可以及早的采取相应的措施。笔者有时候将这种主动出击的行为叫做蜜罐效应。简单的说，就是设置两个服务器。其中一个是真正的服务器，另外一个是蜜罐。现在需要做的是，如何将真正的服务器伪装起来，而将蜜罐推向公众。让攻击者认为蜜罐服务器才是真正的服务器。要做到这一点的话，可能需要从如下几个方面出发。 一是有真有假，难以区分。如果要瞒过攻击者的眼睛，那么蜜罐服务器就不能够做的太假。笔者在做蜜罐服务器的时候，80%以上的内容都是跟真的服务器相同的。只有一些比较机密的信息没有防治在蜜罐服务器上。而且蜜罐服务器所采取的安全措施跟真的服务器事完全相同的。这不但可以提高蜜罐服务器的真实性，而且也可以用来评估真实服务器的安全性。一举两得。 二是需要有意无意的将攻击者引向蜜罐服务器。攻击者在判断一个Web服务器是否值得攻击时，会进行评估。如评估这个网站的流量是否比较高。如果网站的流量不高，那么即使被攻破了，也没有多大的实用价值。攻击者如果没有有利可图的话，不会花这么大的精力在这个网站服务器上面。如果要将攻击者引向这个蜜罐服务器的话，那么就需要提高这个蜜罐服务器的访问量。其实要做到这一点也非常的容易。现在有很多用来交互流量的团队。只要花一点比较小的投资就可以做到这一点。 三是可以故意开一些后门让攻击者来钻。作为Web服务器的管理者，不仅关心自己的服务器是否安全，还要知道自己的服务器有没有被人家盯上。或者说，有没有被攻击的价值。此时管理者就需要知道，自己的服务器一天被攻击了多少次。如果攻击的频率比较高，管理者就高兴、又忧虑。高兴的是自己的服务器价值还蛮大的，被这么多人惦记着。忧虑的是自己的服务器成为了众人攻击的目标。就应该抽取更多的力量来关注服务器的安全。四、专人对Web服务器的安全性进行测试 俗话说，靠人不如靠自己。在Web服务器的攻防战上，这一个原则也适用。笔者建议，如果企业对于Web服务的安全比较高，如网站服务器上有电子商务交易平台，此时最好设置一个专业的团队。他们充当攻击者的角色，对服务器进行安全性的测试。这个专业团队主要执行如下几个任务。 一是测试Web管理团队对攻击行为的反应速度。如可以采用一些现在比较流行的攻击手段，对自己的Web服务器发动攻击。当然这个时间是随机的。预先Web管理团队并不知道。现在要评估的是，Web管理团队在多少时间之内能够发现这种攻击的行为。这也是考验管理团队全天候跟踪的能力。一般来说，这个时间越短越好。应该将这个时间控制在可控的范围之内。即使攻击最后没有成功，Web管理团队也应该及早的发现攻击的行为。毕竟有没有发现、与最终有没有取得成功，是两个不同的概念。 二是要测试服务器的漏洞是否有补上。毕竟大部分的攻击行为，都是针对服务器现有的漏洞所产生的。现在这个专业团队要做的就是，这些已发现的漏洞是否都已经打上了安全补丁或者采取了对应的安全措施。有时候我们都没有发现的漏洞是无能为力，但是对于这些已经存在的漏洞不能够放过。否则的话，也太便宜那些攻击者了。
❼ 如何进行WEB安全性测试
安全性测试
产品满足需求提及的安全能力
n 应用程序级别的安全性，包括对数据或业务功能的访问，应
用程序级别的安全性可确保：在预期的安全性情况下，主角
只能访问特定的功能或用例，或者只能访问有限的数据。例
如，可能会允许所有人输入数据，创建新账户，但只有管理
员才能删除这些数据或账户。如果具有数据级别的安全性，
测试就可确保“用户类型一” 能够看到所有客户消息（包括
财务数据），而“用户二”只能看见同一客户的统计数据。
n 系统级别的安全性，包括对系统的登录或远程访问。
系统级别的安全性可确保只有具备系统访问权限的用户才能
访问应用程序，而且只能通过相应的网关来访问。
安全性测试应用
防SQL漏洞扫描
– Appscan
n防XSS、防钓鱼
– RatProxy、Taint、Netsparker
nget、post -> 防止关键信息显式提交
– get：显式提交
– post：隐式提交
ncookie、session
– Cookie欺骗
❽ 如何进行WEB安全性测试
一般来说，一个WEB应用包括WEB服务器运行的操作系统、WEB服务器、WEB应用逻辑、数据库几个部分，其中任何一个部分出现安全漏洞，都会导致整个系统的安全性问题。
对操作系统来说，最关键的操作系统的漏洞，Windows上的RPC漏洞、缓冲区溢出漏洞、安全机制漏洞等等；
对WEB服务器来说，WEB服务器从早期仅提供对静态HTML和图片进行访问发展到现在对动态请求的支持，早已是非常庞大的系统。
对应用逻辑来说，根据其实现的语言不同、机制不同、由于编码、框架本身的漏洞或是业务设计时的不完善，都可能导致安全上的问题。
对WEB的安全性测试是一个很大的题目，首先取决于要达到怎样的安全程度。不要期望网站可以达到100%的安全，须知，即使是美国国防部，也不能保证自己的网站100%安全。对于一般的用于实现业务的网站，达到这样的期望是比较合理的：
1、能够对密码试探工具进行防范；
2、能够防范对cookie攻击等常用攻击手段；
3、敏感数据保证不用明文传输；
4、能防范通过文件名猜测和查看HTML文件内容获取重要信息；
5、能保证在网站收到工具后在给定时间内恢复，重要数据丢失不超过1个小时；
❾ Web前端密码加密是否有意义
在前端对密码做一次MD5，看起来是防止明文传输了，事实上只有一种情况下它可以提高用户的安全性，那就是用户在别的网站上也用和你的网站一样的密码。并且在任何情况下都提高不了你自己网站的安全性。前面说的传输过程、内存里、日志里……这些地方没有明文密码，其实都只能保护用户本身的利益，对于自身服务的安全性是没有提高的。因为，既然传输过程不是加密的，那么包随便发，至于发一个abc123，还是发一个，对你的程序没有任何的区别，这时候你的程序都是小绵羊。这个过程可以看做，你的用户都用了32位字符串的密码，如是而已。从事实意义上讲，在所有网站上用同样密码的用户非常多，所以可以勉勉强强的说，这是有一丁丁点的意义的。但即使在前端做了签名，因为hash暴露了，也还是很容易被撞库。但是，对安全性没有提高，就不做了吗？当然要做，因为要应付审计。
❿ Web前端密码加密是否有意义
密码在前端加密完全没有意义，对密码系统的安全性不会有任何提高，反而会引发不必要的麻烦。首先，做前端开发的人需要知道，前端系统的控制权是完全在用户手里的，也就是说，前端做什么事情，用户有完全的控制权。假设如同 @陈轩所说，前端做过了md5，后台就不用做了，这个做法会有什么后果？如果某一天，这个系统的数据库泄露了，黑客就直接拿到了每个用户的密码md5值，但此时，由于黑客知道密码是在前端进行哈希的，所以他不需要爆破出该md5对应的原文是什么，而是直接修改客户端向服务器发出的请求，把密码字段换成数据库中MD5就可以了，由于与数据库中记录一致，直接就会登录成功。这跟直接存储明文密码没有任何区别！！！所以不管前端是不是加密了密码，后台使用安全的哈希算法对内容再次转换是非常有必要的。（MD5可不行，要用bcrypt，我之前回答过一个类似的：随着显卡性能的高速发展，目前的快速Hash算法是否已经变得不够安全了？）这个回答还有一个人赞同，希望大家别被错误答案误导了。另外一个答案 @林鸿所说，在非安全HTTP连接上，可以防止原始密码被窃听。但问题在于由于你的登录系统接受的哈希过的密码，而不是原文，窃听者根本不需要原始密码，只要通过哈希结果就可以伪造请求登录系统。这样做只能防止被窃听到原文的密码被攻击者用在社会学攻击上，而不能改善该网站的安全性。所以不管前端是不是加密了密码，使用HTTPS安全连接进行登录都是非常有必要的。以上我说的两点，合起来看就是：不管前端是否加密了密码，都不能以此为假设，让后端设计的安全等级下降，否则就会有严重的安全问题。实际上，前端进行密码加密，可以看做帮助用户多进行了一次原文的转换，不管用了什么加密算法，算出来的结果都是密码原文，你该如何保护用户的原始密码，就该如何保护此处的加密结果，因为对你的登录系统来说，它们都是密码原文。以上这些，说明了密码加密是没有什么意义的，接下来，我要说明前端加密会带来什么问题。有些人会认为前端进行了加密，可以降低后台的安全性需求，这种错误的观念会造成系统的安全漏洞。实际上，你不能对前端做任何的假设，所有跟安全相关的技术，都必须应用在后台上。前端进行加密会造成页面需要js脚本才能运行，那么假设你的系统需要兼容不能运行js的客户端，就必须再设计一个使用原文的登录接口。由于前端是不是加密，所有安全机制都必须照常应用，所以为系统增加这样的复杂性是完全没必要的，即使传输明文密码，只要正确使用了HTTPS连接和服务器端安全的哈希算法，密码系统都可以是很安全的。