企业级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控件是在服务器端运行的,而html控件是客户端运行的
通俗点说就是web控件是在服务器端运行后生成静态代码传给客户端浏览器,html控件就白了就是原来的html标签,是直接被客户端浏览器解释的
如果想要减轻服务器的负担可以采用HTML控件
HTML控件的客户端事件处理比较方便,可以直接在控件中指定,直接调用js函数
如果是WEB 控件就必须采用程序指定了,比如在cs中采用c#函数了

其实你的问题就是web开发下，客户端编程(js)好，还是服务端code behind编程好（比如aspnet)。对于你说的js+webservice的方式，我不敢苟同，这种方式显然受制于webservice的传输。不是一种很好的方法，也不够灵活。在客户端编程，如果要和服务端交互，ajax绝对是首选。 我的经验：1 js编程的优点很明显，用户体验十分好，比如ajax（绝对是客户端服务端交互首选）。所有的界面都是无刷新，让用户在web上能体验到winform一样的 *** 作。当然，这也会对服务器和网络环境有很高的要求。 缺点呢，就是效率低。这个效率低体现在很多方面 1）首先，js做为一种解释型语言，肯定没有c#或者java高级编译语言执行效率高； 2）其次，js（ajax)开发成本和效率，以及维护效率都很低。即使现在比较流行的jquery等框架，也绝对没有aspnet或者java开发框架成熟稳定。开发人员可能会将大部分事件都用在处理代码事件绑定，控件编写上；相比较aspnet和java等成熟型框架，开发人员能够将自己的工作中心，完全转移到业务逻辑上来。对于低级代码的编写，我们对js（ajax)显然更要多多的 *** 心。可想而知，如果一旦系统出了问题，维护起来，很麻烦。举个最简单的例子：垃圾回收。js 经常会出现内存溢出错误。程序运行中此问题甚至不能重现。有时候为了改变这个情况，不得不重新编写架构。耗费大量的时间于技术完善上。有的时候在服务器编程很容易实现的功能，可能要花费很长的时间才能通过客户端编程js实现。 2 对于服务器编码。应该说正好和js客户端编程相反。优点：框架成熟，开发和维护效率高。程序员可以把大部分的精力集中在业务层面上。对于企业级开发来说，大有好处。在基于例如netframe work的框架下，很多东西都是现成的，很容以实现。这个的优点我就不多说了，大家都知道。 缺点呢，我想也是显而易见的，和服务器交互频繁使得用户体验差，由于使用了过的viewstate等服务端容器，使得web页面臃肿不堪，降低页面效率。 另外，也正是由于服务端编程的优点------成熟的框架，使得衍生出其另一个缺点-----灵活性低。 很多东西虽然有现成的，但是我们想个性化定制其功能的时候，不得不受制于控件的功能（当然，这个可以通过编写自定义控件进行改观） 我的观点：对于web开发来说，单纯的认为js(ajax)开发好，或者认为服务端开发好的，都是片面的。最好的网站一定是兼顾 开发，维护，成本，用户体验，效率，资金 等多方面的问题。显然，只有将客户端和服务端开发合二唯一，各自取其优点，才能做出最令人满意的web 应用程序。在功能，用户体验和系统维护可靠性上，才能说是上品。把业务逻辑和主要的编程都采用服务端编程模式，这样利于快速开发和后期维护，也能减低开发成本；而在用户界面和用户体验上使用js(ajax)的开发模式，有利于提高客户的满意度和产品的口碑。所以，可以看到，以微软net为例，把前台显示和后台代码分离进行开发，一直是aspnet不断的追求。这也是我们普通的程序开发人员需要追求的。你若是仔细想想，客户端开发和服务端开发，微软已经为我们想到了：怎么让这两个东西能够融合在一起呢？他们已经给出了最好的答案。 以上是我个人工作经验的总结。有什么问题或者不同意见的，欢迎大家一起来讨论。

html服务器控件和web服务器控件的区别。
1、html控件在已往的静态页面和其他网页里存在,不能在服务器端控制的，只能在客户端通过javascript和vbscript等程序
2、html服务器控件:其实就是html控件的基础上加上runat="server"所构成的控件它们的注意区别是运行方式不同，html控件运行在客户端，而html服务器控件是运行在服务
器端的。 当ASPNET 网页执行时，会检查标注有无runat 属性，如果标注没有设定，那么Html标注就会被视为符串，并被送到字符串流等待送到客户端
，客户端的浏览器会对其进行解释；如果Html标注有设定runat="server" 属性，Page 对象会将该控件放入控制器，服务器端的代码就能对其进行控制，等到控制执行完毕后再将
Html服务器控件的执行结果转换成Html标注，然后当成字符串流发送到客户端进行解释。
如： <input id="Button" type="button" value="button" runat="server" />
3、web服务器控件:也称aspnet服务器控件，是Web Form编程的基本元素，也是aspnet所特有的。它会按照client的情况产生一个或者多个html控件，而不是直接描述html元
素。

近期准备session，希望能跟大家轻松地分享一些东西，一些常见的场景。比如：web后台服务器到底是如何工作的。
上网过程对于普通人：首先，他需要一台电脑，然后，他的电脑可以接入网络，最后，他可以打开浏览器键入自己想要浏览的网址，然后就可以上网了。但是对于计算机来讲，是一个比较复杂的过程，里面包含了信息如何保存，信息如何传递以及信息如何展示的过程。所以，针对整个上网过程，我们从前到后，分析一下其中包含的各种技术细节，可能不全，目的是抛砖引玉，希望大家在简单的流程当中学习更多的东西分享出来，一些基础知识则当做复习。之前buddy王老吉讲过浏览器的工作方式，所以本文内容不包含浏览器的工作方式，重点在于各种后台服务以及通信层面的分析。

前面说到，用户浏览器中键入网址便浏览网页信息，这个网址实际上就是URL，英文全称是Uniform Resource Locator——统一资源定位符。

完整的、带有授权部分的普通统一资源标志符语法看上去如下：
协议://用户名:密码@子域名域名顶级域名:端口号/目录/文件名文件后缀参数=值
协议部分可以是>