知己知彼，方能百战百胜。在提升Web服务安全性的同时，需要先了解Web服务自身的弱点。然后再根据弱点来采取对应的措施。在这篇文章中，笔者就将根据自己的工作经历，分析一下Web服务的弱点，并且这些弱点是容易被人用来进行攻击的。相信这些内容对于大家提高Web的安全性会有很大的帮助。

　　弱点一：不可靠的默认值

　　在Web应用程序设计时，为了提高用户的输入效率，会设置比较多的默认值。但是这些默认值是把双刃剑。即可以提高用户输入的速度，但是也会影响Web应用程序的安全性。举一个简单的例子。Web服务器的默认端口是什么?80。正确。这个信息只要稍微有点Web 知识的人都知道。现在的问题是，大家都知道这个信息，那么攻击者就可以轻而易举的通过这个端口来进行攻击。如可以利用工具扫描80端口是否开启来判断服务器是否启用了Web服务。为此如果Web服务没有改变这个默认的端口值，那么就将导致很多安全问题。再如，有些管理员在设置用户名与密码的时候，可能给用户的默认用户名为空或者跟管理员帐户相同的名字。虽然他们可能提醒用户需要尽快的去更改密码。但是根据笔者的经验，不少用户都没有这个安全意识。

　　可见，为Web应用程序设置默认值时，并不怎么可靠。为此笔者建议，对于一些关键的应用，如端口、管理员帐户名、密码等信息最好不要采用默认值。这会降低Web应用程序的安全性能。

　　弱点二：关键信息没有采取加密处理

　　笔者以前研究过一款Compiere的ERP系统，其有B/S与C/S两种架构。在登陆的时候，需要用户输入用户名与密码。在输入这个信息的时候，密码采用了掩码的形式，这确实可以起到一定的保护效果。但是用户名在后台数据库中存储的，以及从网页客户端传输到应用服务器、数据库服务器的过程中，采用的都是明码的形式。这也就是说，只要攻击者采用一些嗅探工具、或者攻破了数据库，那么对于这个应用来说，攻击者就可以畅通无阻的进行一些破坏行为。相反，如果我们对于这些关键信息都采取了加密处理。那么即使攻击者有了这些数据，对于他们来说，也是没用任何用处。

　　无论是在数据库服务器，还是在客户端的Cookies中，不直接存储没有加密的挂念信息(如密码或者其他私有数据)，这是提高数据安全性的一个首要的原则。如果这些数据暴露了，但是所采用的加密方案将防止暴露用户的密码。

　　了解这个基本的原则之后，那么管理人员就需要关注，该选择使用哪种加密技术。选择的加密技术的不同，直接影响到Web服务的安全性。但是需要注意的是，加密技术也是一把双刃剑。一般来说，在同等条件下，加密级别越高，其需要的资源开销也就越大。简单的说，加密的级别与系统的性能是成反向变动的。

　　弱点三：Web服务的溢出

　　这是最传统的、也是危害最大的一个弱点。最早遭受破坏的、且仍旧普遍的攻击来源于开发人员对最终用户输入的数据的可信任假设。其实这种假设是非常危险的。我们做安全的人员，应该保持一种执业的怀疑态度。即将用户假设为攻击者。只有如此，才能够做好安全工作。但是不少开发人员没有这种安全意识。举一个简单的例子。如果一个用户了解PowerPoint文件格式的相关内容，他们就可以利用文本编辑器来编写一个PowerPoint的文件。编辑的工作相当简单，只是让内部字段中拥有的数据比系统允许的更多的数据，此时就会导致系统崩溃。然后攻击者就可以执行任何想要执行的程序。这种攻击手段就叫做溢出攻击。其适用于大部分Web服务器。

　　简单地说，溢出性攻击是由于将太多的数据放入原始程序设计人员认为足够的空间中导致。额外的数据溢出将包存储到附近的内存中，并且覆盖与这个区域的原始用途无关的数据。当执行其他应用程序时，程序就会使用新的数据。这也就是说，如果攻击者能够使用错误的数据填充足够的空间，并在数据中添加一些恶意的代码，那么应用程序就可能会执行恶意代码，从而实现其攻击的目的。如删除数据、更新网站主页等等。如果受到攻击的应用程序是有系统管理员启动的，此时恶意代码就可能作为原始程序的一部分执行，从而给攻击者管理员特权。当攻击者获取管理员特权时，那么后果就可想而知了。

　　对于Web服务来说，需要特别注意缓冲区溢出攻击。在缓冲区溢出攻击实例中，程序的内部值将会被溢出，从而改变程序的运行方式。在应用程序的正常操作过程中，当调用一个函数时，被调用函数的所有参数以及返回位置的指针就会被存储在内存中。当完成这个函数规定的作业之后，使用返回指针将会回到原来到位置并继续执行其他的程序。利用缓冲区溢出进行攻击就可以改变这个过程。即让函数执行攻击者所希望执行的程序或者代码。通过输入足够多的数据来覆盖原有的参数，以及输入到不同函数的新返回指针就可以实现。

　　可见，溢出这个弱点，对于Web服务来说是非常致命的。不过要弥补这个漏洞难度也不是很大。一般来说，开发人员只需要在开发过程中做好相关的检查工作，就可以弥补。如在文本框中，在用户保存数据之前进行必要的检查。包括数据类型、数据中是否包含着不允许的特殊字符等等。这也就是说，在开发Web应用程序的时候，应该对用户保持必要的怀疑态度。只有如此，才会去思考如何来检验用户的数据。这么操作完成之后，就可以在很大程度上避免溢出攻击，提高应用服务器的安全。

　　弱点四：SQL注入式攻击

　　SQL注入式攻击漏洞是与缓冲区溢出攻击，可以称兄道弟。除了溢出弱点，SQL注入是另一类依赖于开发人员没有测试输入数据而导致的攻击。如大多数人拥有字符数字或者秘密，或者有安全意识的人，拥有附带其他键盘符号的字符数字式密码，这可以提高密码的安全程度。出于这种安全的考虑，开发人员可能会允许用户输入任何字符作为密码。但是如果在开发过程中，没有做好严格的检查，那么就可能会造成Web服务器的SQL注入式攻击。

　　SQL注入式攻击的原理非常的简单。在网络上关于其的资料也有一大把。为此笔者不在这里过多的阐述。笔者只是强调一下，在开发Web应用程序时，SQL注入式攻击应该引起开发人员的重视。采取积极的措施来消除这个弱点。

　　根据以前的攻击案例，可以知道这个弱点是针对Web应用程序最有效的攻击手段之一。而且随着大家对Web应用程序信任的增加(如网上转帐等业务的应用)，其危害性也就越来越大。

　　其实要防止这个攻击也比较简单。主要就是应用程序在开发时，要加强对用户输入数据的检测。如对于用户输入字符的长度、字符的格式等等内容进行比较严格的限制，并在用户输入数据后、保存数据之前进行严格的检查。只要做好输入检查这一段，基本上就可以消除这个弱点所带来的安全威胁。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。