web系统安全页面加密

⑴ Web前端密码加密是否有意义

在前端对密码做一次MD5，看起来是防止明文传输了，事实上只有一种情况下它可以提高用户的安全性，那就是用户在别的网站上也用和你的网站一样的密码。并且在任何情况下都提高不了你自己网站的安全性。前面说的传输过程、内存里、日志里……这些地方没有明文密码，其实都只能保护用户本身的利益，对于自身服务的安全性是没有提高的。因为，既然传输过程不是加密的，那么包随便发，至于发一个abc123，还是发一个，对你的程序没有任何的区别，这时候你的程序都是小绵羊。这个过程可以看做，你的用户都用了32位字符串的密码，如是而已。从事实意义上讲，在所有网站上用同样密码的用户非常多，所以可以勉勉强强的说，这是有一丁丁点的意义的。但即使在前端做了签名，因为hash暴露了，也还是很容易被撞库。但是，对安全性没有提高，就不做了吗？当然要做，因为要应付审计。

⑵ Web前端密码加密是否有意义

密码在前端加密完全没有意义，对密码系统的安全性不会有任何提高，反而会引发不必要的麻烦。

(1)加密了也无法解决重放的问题，你发给服务器端的虽然是加密后的数据，但是黑客拦截之后，把加密之后的数据重发一遍，依然是验证通过的。直接监听到你所谓的密文，然后用脚本发起一个http请求就可以登录上去了。

http在网络上是明文传输的，代理和网关都能够看到所有的数据，在同一局域网内也可以被嗅探到，你可以开个wireshark抓下局域网的包试试看。加密也没有提高什么攻击难度，因为攻击者就没必要去解密原始密码，能登录上去就表示目标已经实现了，所以，难度没有提高。

(2)既然是加密，那么加密用的密钥和算法肯定是保存在前端的，攻击者通过查看源码就能得到算法和密钥。除非你是通过做浏览器插件，将算法和密钥封装在插件中，然后加密的时候明文混淆上时间戳，这样即使黑客拦截到了请求数据，进行重放过程时，也会很快失效。

⑶ Web前端密码加密是否有意义

没有意义

---

密码前端的加密根本没有意义，密码系统的安全性没有提高，但会造成不必要的麻烦。

首先，前端开发人员需要知道前端系统的控制完全掌握在用户手中，也就是说前端所做的事情和用户拥有完全的控制。据称，前端做了MD5，后台不必做，这种方法会有什么后果？如果有一天，系统数据库泄露，黑客直接获得每个用户的密码的MD5值，但这一次，因为黑客知道密码的哈希的前面，所以他不需要鼓风的MD5对应什么是原创，而是直接修改发送到服务器的客户端请求的在它的数据库密码字段MD5，符合数据库中的记录，你可以直接登录。这与直接存储明文密码没有区别！！！所以不管前端密码是否加密，后台使用哈希算法的安全内容转换都是必要的。（MD5不能使用BCrypt的，我以前回答类似：用图形表现，当前快速发展的快速哈希算法已成为不安全吗？）有一个人同意这个答案，我希望你不要被错误的答案误导。对方的回答，Linh说，是为了防止原始密码被利用在一个不安全的HTTP连接。但问题是，因为你的登录系统接受密码代替原来的，窃听者根本不需要原始密码，只要哈希结果可以伪造请求登录系统。这样做只会防止攻击者在社交攻击时使用原始密码，而不会提高网站的安全性。所以不管前面密码是不是加密的，使用HTTPS安全连接登录都是很有必要的。

⑷ 怎样给html网页加密

三、使用ASP程序密码锁

除了使用IIS服务器来给网页加密，我们还可以使用ASP程序来给网页进行加密，一般来说利用程序来进行密码验证的方法比较通用，现在大多数网站都使用ASP程序，它对Web服务器没有具体要求，而其加密就是借助数据库及ASP程序进行设计，来实现一种通用网页加密。

1. 打开Microsoft Access，建立一个“用户名及密码”的数据表，假设将这个表取名为User，数据库名为lastcoco.mdb，数据表的结构如下：

字段说明 字段名称 数据类型 数据长度

用户名称 ID文本 15

密码 PWD 文本 15

2. 编辑一个PASS.ASP的验证文件，源代码如下：

＜%Function Check( ID, Pwd )Dim conn, par, rsSet conn = Server.CreateObject("ADODB.Connection")par = "driver={Microsoft Access Driver (*.mdb)} "conn.Open par && ";dbq=" && Server.MapPath("lastcoco.mdb ")sql = "Select ? From users Where ID='" && ID && "' And Pwd = '" && Pwd &&"'"Set rs = conn.Execute( sql )If rs.EOF ThenCheck= FalseElseCheck= TrueEnd IfEnd Function%＞＜%If IsEmpty(Session("Passed")) Then Session("Passed") = FalseHead = "请输入用户名和密码"ID = Request("ID")Pwd = Request("Pwd")If ID = "" Or Pwd = "" ThenHead = "请输入用户名和密码"Else If Not Check( ID, Pwd ) ThenHead = "用户名称或密码有错"ElseSession("Passed") = TrueEnd IfIf Not Session("Passed") Then %＞＜html＞＜head＞ ＜title＞＜/title＞ ＜/head＞＜body BGCOLOR="#FFFFFF"＞＜h2 ALIGN="CENTER"＞＜%=Head%＞＜/h2＞＜hr WIDTH="100%"＞＜form Action="＜%=Request.ServerVariables("PATH_INFO")%＞" Method="POST"＞＜table BORDER="1" CELLSPACING="0"＞＜tr＞＜td ALIGN="RIGHT"＞用户名称:＜/td＞＜td＞＜input Type="Text" Name="ID" Size="12" Value="＜%=ID%＞"＞＜/td＞＜/tr＞＜tr＞ ＜td ALIGN="RIGHT"＞密码：＜/td＞＜td＞＜input Type="Password" Name="Pwd" Size="12" Value="＜%=Pwd%＞"＞＜/td＞ ＜/tr＞＜/table＞＜p＞＜input Type="Submit" Value="确定"＞ ＜/p＞ ＜/form＞＜hr WIDTH="100%" align="center"＞＜/body＞ ＜/html＞＜%Response.EndEnd If %＞

3. 在需要加密网页的HTML代码最前面加上〈! --#include file="pass.asp"--〉就可以了。由于这个验证合法性的页面具有通用性，所以非常方便使用。

四、使用软件密码锁

现在给网页加密的软件非常多，这里就不一一讲解，其基本原理都是利用javascript代码，只不过是这些软件都自动准备好了这些代码，只需使用者将网页源代码粘进去按一下加密按钮就OK了。

在这里我们介绍一款绿色的小软件“世纪鸟网页加密精灵”，大家不要小看这只鸟，通过这只小鸟，能更方便快速的对网页进行加密。

下载双击打开这只小鸟，只见XP风格的界面跳到眼前，左边竖着一排是加密选项按钮，分别是“网页代码加密”、“网页登录密码”“鼠标右键屏蔽”、“网页选择屏蔽”、“鼠标右键对话”、“框架包含限制”这些。右边则是网页代码加密对话框，在这个对话框中进行对网页的加密，而且在对话框上方给出每个选项的解释，在对话框下方则是建议。

这里我用实例给大家讲解使用“世纪鸟网页加密精灵”的“网页登录密码”选项来给网页加密。

1. 打开要加密的网页，复制出HTML源代码，然后打开“世纪鸟网页加密精灵”软件，选择“网页登录密码”选项，这时在右边就会出现一些输入框内的代码说明
2. 在“请输入登录密码”的输入框中输入长度小于10位的密码，然后单击“生成并复制密码页面程序”按钮，这时软件会自动在下方的javascript代码中加入你输入的登录密码做为验证信息，并将这段代码复制到你的剪贴版中
3. 接下来再将这段代码粘贴到网页中，并将网页改名为（你输入的登录密码）.htm，这样就可以对此文件加密了

⑸ 如何用IPS解决Web安全问题

（一）加密技术。
加密技术是电子商务采取的基本安全措施，交易双方可根据需要在信息交换的阶段使用。加密技术分为两类，即对称加密和非对称加密。
（1）对称加密。
对称加密又称私钥加密，即信息的发送方和接收方用同一个密钥去加密和解密数据。它的最大优势是加/解密速度快，适合于对大数据量进行加密，但密钥管理困难。如果进行通信的双方能够确保专用密钥在密钥交换阶段未曾泄露，那么机密性和报文完整性就可以通过这种加密方法加密机密信息、随报文一起发送报文摘要或报文散列值来实现。
（2）非对称加密。
非对称加密又称公钥加密，使用一对密钥来分别完成加密和解密操作，其中一个公开发布（即公钥），另一个由用户自己秘密保存（即私钥）。信息交换的过程是：甲方生成一对密钥并将其中的一把作为公钥向其他交易方公开，得到该公钥的乙方使用该密钥对信息进行加密后再发送给甲方，甲方再用自己保存的私钥对加密信息进行解密。
（二）认证技术。
认证技术是用电子手段证明发送者和接收者身份及其文件完整性的技术，即确认双方的身份信息在传送或存储过程中未被篡改过。
（1）数字签名。
数字签名也称电子签名，如同出示手写签名一样，能起到电子文件认证、核准和生效的作用。其实现方式是把散列函数和公开密钥算法结合起来，发送方从报文文本中生成一个散列值，并用自己的私钥对这个散列值进行加密，形成发送方的数字签名；然后，将这个数字签名作为报文的附件和报文一起发送给报文的接收方；报文的接收方首先从接收到的原始报文中计算出散列值，接着再用发送方的公开密钥来对报文附加的数字签名进行解密；
（2）数字证书。
数字证书是一个经证书授权中心数字签名的包含公钥拥有者信息以及公钥的文件数字证书的最主要构成包括一个用户公钥，加上密钥所有者的用户身份标识符，以及被信任的第三方签名第三方一般是用户信任的证书权威机构（CA），如政府部门和金融机构。用户以安全的方式向公钥证书权威机构提交他的公钥并得到证书，然后用户就可以公开这个证书。任何需要用户公钥的人都可以得到此证书，并通过相关的信任签名来验证公钥的有效性。数字证书通过标志交易各方身份信息的一系列数据，提供了一种验证各自身份的方式，用户可以用它来识别对方的身份。

⑹ 如何对web.config进行加密和解密

你好，可以使用受保护配置来加密 Web 应用程序配置文件（如 Web.config 文件）中的敏感信息（包括用户名和密码、数据库连接字符串和加密密钥）。对配置信息进行加密后，即使攻击者获取了对配置文件的访问，也可以使攻击者难以获取对敏感信息的访问，从而改进应用程序的安全性。 针对asp.net 2.0的应用程序的数据库链接字符串进行加密：例如，未加密的配置文件中可能包含一个指定用于连接到数据库的连接字符串的节，如下面的示例所示： <configuration> <connectionStrings>
<add name="SampleSqlServer" connectionString="Data Source=localhost;Integrated Security=SSPI;Initial Catalog=Northwind;" />
</connectionStrings>
</configuration>
ASP.NET 2.0 中有一个新的安全特性.可以对 Web.config 文件中的任何配置节进行加密处理，可以通过手工运行工具aspnet_regiis或者编程来完成这个工作。如果你可以直接访问你的Web 服务器，你可以通过运行如下的命令行： cd %windows%/Microsoft.NET/Framework/versionNumber aspnet_regiis -pe "connectionStrings" -app "/SampleApplication" –prov -pd section
对配置节进行解密。此参数采用下面的可选参数： · -app virtualPath 指定应该在包含路径的级别进行解密。 · -location subPath 指定要解密的子目录。 · -pkm 指定应该对 Machine.config 而非 Web.config 文件进行解密。

-pdf section webApplicationDirectory
对指定物理（非虚拟）目录中的 Web.config 文件的指定配置节进行解密。

-pe section
对指定的配置节进行加密。此参数采用下面的可选修饰符： · -prov provider 指定要使用的加密提供程序。 · -app virtualPath 指定应该在包含路径的级别进行加密。 · -location subPath 指定要加密的子目录。 · -pkm 指定应该对 Machine.config 而非 Web.config 文件进行加密。

-pef section webApplicationDirectory
对指定物理（非虚拟）目录中的 Web.config 文件的指定配置节进行加密。
如果你是使用虚拟主机等不能访问物理的服务器,你仍然能够通过编程方式加密的连接字符串: 1 Configuration config = Configuration.GetWebConfiguration(Request.ApplicationPath);
2 ConfigurationSection section = config.Sections["connectionStrings"];
3 section.SectionInformation.ProtectSection("");;
4 config.Update ();或者 config.Save();

//加密web.Config中的指定节
private void ProtectSection(string sectionName)
{
Configuration config = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section = config.GetSection(sectionName);
if (section != null && !section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection("");
config.Save();
}
}

//解密web.Config中的指定节
private void UnProtectSection(string sectionName)
{
Configuration config = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection section = config.GetSection(sectionName);
if (section != null && section.SectionInformation.IsProtected)
{
section.SectionInformation.UnprotectSection();
config.Save();
}
}

⑺ Web前端密码加密是否有意义

密码在前端加密完全没有意义，对密码系统的安全性不会有任何提高，反而会引发不必要的麻烦。首先，做前端开发的人需要知道，前端系统的控制权是完全在用户手里的，也就是说，前端做什么事情，用户有完全的控制权。假设如同 @陈轩所说，前端做过了md5，后台就不用做了，这个做法会有什么后果？如果某一天，这个系统的数据库泄露了，黑客就直接拿到了每个用户的密码md5值，但此时，由于黑客知道密码是在前端进行哈希的，所以他不需要爆破出该md5对应的原文是什么，而是直接修改客户端向服务器发出的请求，把密码字段换成数据库中MD5就可以了，由于与数据库中记录一致，直接就会登录成功。这跟直接存储明文密码没有任何区别！！！所以不管前端是不是加密了密码，后台使用安全的哈希算法对内容再次转换是非常有必要的。（MD5可不行，要用bcrypt，我之前回答过一个类似的：随着显卡性能的高速发展，目前的快速Hash算法是否已经变得不够安全了？）这个回答还有一个人赞同，希望大家别被错误答案误导了。另外一个答案 @林鸿所说，在非安全HTTP连接上，可以防止原始密码被窃听。但问题在于由于你的登录系统接受的哈希过的密码，而不是原文，窃听者根本不需要原始密码，只要通过哈希结果就可以伪造请求登录系统。这样做只能防止被窃听到原文的密码被攻击者用在社会学攻击上，而不能改善该网站的安全性。所以不管前端是不是加密了密码，使用HTTPS安全连接进行登录都是非常有必要的。以上我说的两点，合起来看就是：不管前端是否加密了密码，都不能以此为假设，让后端设计的安全等级下降，否则就会有严重的安全问题。实际上，前端进行密码加密，可以看做帮助用户多进行了一次原文的转换，不管用了什么加密算法，算出来的结果都是密码原文，你该如何保护用户的原始密码，就该如何保护此处的加密结果，因为对你的登录系统来说，它们都是密码原文。以上这些，说明了密码加密是没有什么意义的，接下来，我要说明前端加密会带来什么问题。有些人会认为前端进行了加密，可以降低后台的安全性需求，这种错误的观念会造成系统的安全漏洞。实际上，你不能对前端做任何的假设，所有跟安全相关的技术，都必须应用在后台上。前端进行加密会造成页面需要js脚本才能运行，那么假设你的系统需要兼容不能运行js的客户端，就必须再设计一个使用原文的登录接口。由于前端是不是加密，所有安全机制都必须照常应用，所以为系统增加这样的复杂性是完全没必要的，即使传输明文密码，只要正确使用了HTTPS连接和服务器端安全的哈希算法，密码系统都可以是很安全的。