网上应用系统保安
网络技术的发展加上企业环境的改变，意味着现今网上应用系统在公司丶公共与政府服务中变得更加盛行。虽然网上应用系统可带来便利和提升效率，但也产生新的保安威胁，若未作好妥善处理，对机构中的资讯科技架构可能会造成潜在而显着的风险。
现今传统网络保安措施与技术已不足以保障网上应用系统和避免新的威胁，尤其是现在的攻击瞄准了网上应用系统设计上的保安漏洞，在发展应用系统时需同时考虑衡量技术和管理两者的保安。
网上应用系统的一般保安漏洞
OWSAP是一个遍布世界的自愿参加者社群，目标是让网上应用系统的保安显而易见。人们和机构可以根据应用系统保安风险的资讯作出决策。
透过 OWASP的指导以建立网上应用系统的保安是一个不错的参考机构归纳出网上应用系统十大关键保安漏洞，系统的开发者应该注意这些一般性的保安漏洞，并制定程式开发的标准，避免这样的问题在编码阶段发生。
1.
跨网址程式编程攻击（Cross Site Scripting, XSS）
跨网址程式编程攻击（XSS）的潜在威胁是允许在受害者的浏览器执行手稿程式（Script），导致劫持用户对话丶窜改网站并可能植入蠕虫等等。此保安漏洞是由应用系统读入了没有经过验证或加密的数据并将它传给浏览器所造成。
跨网址程式编程攻击（XSS）的潜在威胁是允许在受害者的浏览器执行手稿程式（Script），导致劫持用户对话丶窜改网站并可能植入蠕虫等等。此保安漏洞是由应用系统读入了没有经过验证或加密的数据并将它传给浏览器所造成。
2.
植入式保安漏洞
这一个保安漏洞的潜在威胁是攻击者可透过非预期的命令或改变系统数据藉以欺骗应用系统。植入式保安漏洞中尤以在网上应用系统的 SQL 插入漏洞最为常见。当使用者提供的数据被传送到诠释器作为命令或查询时，就会产生植入式攻击。
这一个保安漏洞的潜在威胁是攻击者可透过非预期的命令或改变系统数据藉以欺骗应用系统。植入式保安漏洞中尤以在网上应用系统的 SQL 插入漏洞最为常见。当使用者提供的数据被传送到诠释器作为命令或查询时，就会产生植入式攻击。
3.
恶意程式执行
易于受远程文件包含（ Remote File Inclusion, RFI）破坏的程式码的潜在威胁是允许攻击者有机会引入恶意程式码与数据，导致毁灭性的攻击如入侵整个伺服器。恶意程式执行的攻击会影响到 PHP丶 XML以及任何可接收使用者的档名或档案的架构。
易于受远程文件包含（ Remote File Inclusion, RFI）破坏的程式码的潜在威胁是允许攻击者有机会引入恶意程式码与数据，导致毁灭性的攻击如入侵整个伺服器。恶意程式执行的攻击会影响到 PHP丶 XML以及任何可接收使用者的档名或档案的架构。
4.
不安全的直接物件参照
这个潜在威胁是攻击者不需要透过授权就可以操作接达其他物件的参照。当开发者展示内部完成物件的参照时，例如档案丶目录丶数据库记录或键值作为划一资源定位（ URL）或表单文件的参数，直接物件参照便会发生。
这个潜在威胁是攻击者不需要透过授权就可以操作接达其他物件的参照。当开发者展示内部完成物件的参照时，例如档案丶目录丶数据库记录或键值作为划一资源定位（ URL）或表单文件的参数，直接物件参照便会发生。
5.
跨网站请求伪造（ Cross Site Request Forgery, CSRF）
这一个保安漏洞的潜在威胁是强迫登入者的浏览器寄发预先验证的要求给具保安漏洞的网上应用系统后，强迫使用者的浏览器执行恶意行为而使攻击者获利。 CSRF攻击可与其所攻击的网上应用系统的权力一样。
这一个保安漏洞的潜在威胁是强迫登入者的浏览器寄发预先验证的要求给具保安漏洞的网上应用系统后，强迫使用者的浏览器执行恶意行为而使攻击者获利。 CSRF攻击可与其所攻击的网上应用系统的权力一样。
6.
资料泄漏和不适当误差处理
这个保安漏洞的潜在威胁是攻击者可以使用这个弱点窃取敏感数据，或导致更多严重的攻击。应用系统所存在的多种问题可使其不故意地泄露有关内部组态的资讯丶工作或违反隐私权。
这个保安漏洞的潜在威胁是攻击者可以使用这个弱点窃取敏感数据，或导致更多严重的攻击。应用系统所存在的多种问题可使其不故意地泄露有关内部组态的资讯丶工作或违反隐私权。
7.
身份验证功能和对话管理的缺失
此点的潜在威胁是攻击者可能会组合密码丶密码匙或授权的权标以假装成其他使用者的身份。当帐户凭证与交谈的权标没有受到合适的保护时会造成这个保安漏洞。
此点的潜在威胁是攻击者可能会组合密码丶密码匙或授权的权标以假装成其他使用者的身份。当帐户凭证与交谈的权标没有受到合适的保护时会造成这个保安漏洞。
8.
不安全的加密储存设备
这个潜在的威胁在于当攻击者使用未经妥善保护的数据来进行身份盗窃与其他的犯罪行为，例如伪造信用卡。这个漏洞是由于网上应用系统并没有做好加密的功能以保护数据和凭证。
这个潜在的威胁在于当攻击者使用未经妥善保护的数据来进行身份盗窃与其他的犯罪行为，例如伪造信用卡。这个漏洞是由于网上应用系统并没有做好加密的功能以保护数据和凭证。
9.
未加密的网络通讯
这个保安漏洞来自网络通讯架构传输数据时可能泄漏敏感性资料。原因是当需要保护传输敏感数据的网络通讯时，该网络的传输并没有加密。
这个保安漏洞来自网络通讯架构传输数据时可能泄漏敏感性资料。原因是当需要保护传输敏感数据的网络通讯时，该网络的传输并没有加密。
10.
无权限的划一资源定位（ URL）接达
这一个保安漏洞使攻击者透过直接接达 URL而有机会进行未授权的操作。这个保安漏洞的形成是因为当应用程式避免显示连结或 URL给未授权的使用者时，只保护某些部份敏感的功能。
这一个保安漏洞使攻击者透过直接接达 URL而有机会进行未授权的操作。这个保安漏洞的形成是因为当应用程式避免显示连结或 URL给未授权的使用者时，只保护某些部份敏感的功能。
保护网上应用系统的行政措施
为了强化网上应用系统的保安与协助数据处理的保护，以下是行政方面的建议措施。
为发展与维护网站和 /或网上应用系统提供一个方向并列入关键的指引。
把网上应用系统编码与发展的作业实务列入关键的指引。软件发展小组应遵守一系列安全的网上应用系统编码作业实务，用来抵抗一般的网上应用程式保安漏洞。
收集和管理敏感资讯及使用者数据时要符合政策与法规。
编制保安及品质保证计划，并采用品质保证方法，如重新检查原始码丶渗透测试丶用户验收测试等等。
在网上应用系统推出前或系统作出任何重大更改或升级后，进行完整的资讯科技保安审计。
保护网上应用系统的技术措施
部署网上应用系统带来好处亦带来了新的保安风险。为了有效地处理这些风险，在整个发展周期中应该考虑多样化的保安控制。为了帮助了解所建议的保安控制与发展周期中地方可能相关的地方，本节将透过发展周期的各阶段指出需要特别注意的保安考虑。
需求阶段
在本阶段中应用系统发展小组应该收集和项目有关的部门所需的所有系统与保安规格。系统需求应提供发展小组这应用系统的主要目的概览，包含这个应用系统什麽该做及什麽不该做。此资讯将协助发展小组定义应用系统关键的保安控制。
正确地建立系统和使用者的保安需求在设计丶发展和测试阶段中是非常重要的，这将增加网上应用系统全面性的保安，并确保使用者对结果满意度。
设计阶段
设计阶段所牵涉的不只要求应用系统的设计须和第一阶段所提的规格一致，还须定义安全的编码标准丶执行 threat modelling并发展应用系统的保安架构。
定义安全的编码标准
执行 Threat Modelling模式
设计网上应用程式保安的架构
定义安全的编码标准
安全的编码标准是告诉开发人员如何去撰写应用系统的程式码丶开发保安程式码时的指引，对识别高风险区域丶数据输入与其它界面和误差处理等如何作出适当的评论。不同的机构包括 OWASP和电脑紧急应变小组（Computer Emergency Response Team, 或 CERT）建议一些安全的编码作业实务。
1.
验证所有输入参数的有效性，以防止 SQL插入攻击及跨网址程式编程攻击：
程式设计师应发展一个集中模组，以验证输入参数。
程式设计师应根据允许输入参数类型的格式，检查各项输入参数
过滤 "~!#$%^&*[]<>'\r\n" 等特殊字符的输入，
不可依赖客户端手稿程式去进行必须的验证
应用系统必须只能接受那些严格限制与预期的字符数据，若一数字符合预期，只有数字的字符可被接受，若是文字则只有字母可被允许。输入数据的形式是否合适也应作出验证，若预期是一个电邮地址，则应透过适当安排的文字丶数字丶@符号丶破折号及点号作出验证。
所有进入应用系统的数据应强制最小或最大长度。此技术应使用在帐户号码，交谈凭证与使用者名称等等。所有这些技术限制了入侵攻击潜在缺口的数目。
2.
对应用程式回应进行净化（ Sanitised application response）
应发展一个集中模组，以进行净化工作。检查所有输出丶调用返回码及错误码（例如后端数据库的调用），以确保跟据预期的处理程序执行。举例说，在回应中不必要的内部系统资料，如内部IP地址丶内部主机名称丶内部目录结构丶内部伺服器错误的详细错误信息不应泄露在客户端。大多数应用系统／网站伺服器允许自订错误页面。
应发展一个集中模组，以进行净化工作。检查所有输出丶调用返回码及错误码（例如后端数据库的调用），以确保跟据预期的处理程序执行。举例说，在回应中不必要的内部系统资料，如内部IP地址丶内部主机名称丶内部目录结构丶内部伺服器错误的详细错误信息不应泄露在客户端。大多数应用系统／网站伺服器允许自订错误页面。
3.
超文本传输规约（ HTTP）的可信性
程式编写员不应信赖及依赖 HTTP REFERER标头丶表单字段或 cookies 确定保安措施，因这些数据均可被伪冒。除非采用了有效的加密算法核实HTTP标头是否完整，否则不要信赖这些来自客户浏览器的参数。此外由于隐藏参数容易被攻击者操纵，故不能认为用户无法修改隐藏参数。
程式编写员不应信赖及依赖 HTTP REFERER标头丶表单字段或 cookies 确定保安措施，因这些数据均可被伪冒。除非采用了有效的加密算法核实HTTP标头是否完整，否则不要信赖这些来自客户浏览器的参数。此外由于隐藏参数容易被攻击者操纵，故不能认为用户无法修改隐藏参数。
4.
保护敏感的对话值
保存伺服器上敏感的对话值以防客户端修改。不应将敏感资料储存在任何客户浏览器的 cookies 中。倘若敏感数值不得不储存在客户浏览器中，应采用较强的加密技术保护数据的机密性及完整性。
保存伺服器上敏感的对话值以防客户端修改。不应将敏感资料储存在任何客户浏览器的 cookies 中。倘若敏感数值不得不储存在客户浏览器中，应采用较强的加密技术保护数据的机密性及完整性。
5.
加密含有敏感资料的页面及防止快取记忆
在传输过程中，含有敏感资料的页面应使用适当的算法及密码匙进行加密，例如保密插口层（ Secure Socket Layer, SSL）丶传输层保安（Transport Layer Security, TLS）。使用已签署的 Java微应用程式或 ActiveX 获取及显示敏感资料，及设置适当的 HTTP标头属性，以防止浏览器或代理伺服器对含有敏感资料的个别页面进行快取记忆。
在传输过程中，含有敏感资料的页面应使用适当的算法及密码匙进行加密，例如保密插口层（ Secure Socket Layer, SSL）丶传输层保安（Transport Layer Security, TLS）。使用已签署的 Java微应用程式或 ActiveX 获取及显示敏感资料，及设置适当的 HTTP标头属性，以防止浏览器或代理伺服器对含有敏感资料的个别页面进行快取记忆。
6.
对话管理
对话识别码应比较长丶复杂并包含难以预测的随机数字。在对话中，应经常更改对话识别码，以缩短对话识别码的有效期。此外，对话识别码不应储存在划一资源定位丶永久性 cookies 丶隐藏的超文本标示语言字段及 HTTP标头中。程式编写员可考虑在客户浏览器的对话 cookies 中储存对话识别码。透过保密插口层／传输层保安保护对话识别码，使攻击者无法从网络中窃取。应用系统应提供登出功能及执行闲置对话超时。当用户登出后或闲置对话过期时，须确保不但删除客户端的 cookies（如可能的话），亦删除浏览器的伺服器端对话状态及与后端伺服器的连接。
对话识别码应比较长丶复杂并包含难以预测的随机数字。在对话中，应经常更改对话识别码，以缩短对话识别码的有效期。此外，对话识别码不应储存在划一资源定位丶永久性 cookies 丶隐藏的超文本标示语言字段及 HTTP标头中。程式编写员可考虑在客户浏览器的对话 cookies 中储存对话识别码。透过保密插口层／传输层保安保护对话识别码，使攻击者无法从网络中窃取。应用系统应提供登出功能及执行闲置对话超时。当用户登出后或闲置对话过期时，须确保不但删除客户端的 cookies（如可能的话），亦删除浏览器的伺服器端对话状态及与后端伺服器的连接。
7.
限制终端用户的接达权
确保终端用户帐户仅有权接达获授权的操作程式，并限制接达后端数据库，或运行结构化查询语言指令丶操作系统指令。如应用系统向接达程式作出系统调用，不应直接调用真实档案名称及目录路径。倘若攻击者获取源码，则可发现系统资料。利用网站伺服器的对映功能作为过滤
确保终端用户帐户仅有权接达获授权的操作程式，并限制接达后端数据库，或运行结构化查询语言指令丶操作系统指令。如应用系统向接达程式作出系统调用，不应直接调用真实档案名称及目录路径。倘若攻击者获取源码，则可发现系统资料。利用网站伺服器的对映功能作为过滤
8.
建立应用系统审计及报告的中央模组
9.
使用最适当的认证方法识别及验证输入的用户查询
执行 Threat Modelling模式
建立安全的应用系统需要了解此应用系统所面对的威胁， Threat Modelling的过程可协助我们确定在整体应用程式方案上的威胁丶攻击丶漏洞与抵御措施。
Threat Modelling可透过以下步骤达成：
步骤一：
确定关键的保安目的。
步骤二：
将应用系统的重要特性列出并建立整体的看法。
步骤三：
解构应用系统以确认需要被评估而会影响特性与模组的安全。
步骤四：
确定所有威胁。
步骤五：
确定所有保安漏洞。
设计网上应用程式保安的架构
网上应用系统结构一般包括三个层级，把对外网站伺服器丶内部的应用系统伺服器及数据库伺服器隔开。凭藉这些层级结构，即使攻击者可入侵对外网站伺服器，其仍需另寻方法攻击内部网络。这是纵深防御的原则。
这是纵深防御的原则，纵深防御对资讯保安而言是一个实用的方法，其基本概念主要是在于多层次的保安以保护重要资产。保安的层次包含输入验证，数据库层的概念，伺服器的组态，代理伺服器丶网上应用系统防火墙丶数据加密与作业系统强化等。
发展阶段
就减低程式码保安论点疑虑而言，这是最重要的阶段。注意到保安编码标准可协助改善保安状况，并减少会导致保安事故之常见错误发生的次数。此外执行保安风险评估，也有助于确认所需的保安控制。
测试与品质保证阶段
在任何应用系统推出前，全面测试是非常重要的。除用户验收测试之外，尚有其他测试，例如系统测试丶压力测试丶廻归测试丶和单元测试等对于验证系统功能的效能和准确性是有用的。本节叙述一些测试，可用来增加已发展的程式或系统的可靠性与安全程度。
网上应用系统单元测试
网上应用系统单元测试是发展阶段中的一个重要部份，其设计是用来协助确定网上应用系统中的保安漏洞。单元测试包含了个别程式或模组的测试，以确保程式内部的操作或模组的执行与规格一致。单元测试应包括对一般保安问题的测试，例如缓冲区溢出，尤其当模组与其他组件合并，此测试更为重要。如果没有执行单元测试，便很难在发展阶段中执行自动保安测试程序。
有许多不同的工具，能帮助找出并消除网上应用系统的保安漏洞。但值得注意的是，这些工具只能应付一小部分有效的网络保安应用程式所需之测试。只是依赖这些工具，而不集中改善软件发展生命周期的保安，这是错误的保安观念，因为自动扫描工具的能力仍只限于找出及确定某种类的保安漏洞。
编码覆检
编码覆检能帮助确定出保安漏洞，确保维持保安发展标准及整体程式设计的一致性。一般而言系统发展经理丶系统管理员丶与数据库的管理员，会一起检查应用程式原始码的运作，并作出适当的建议加以改善。此外藉由对原始码的检视，可以确定及评估隐藏或保安性的内容，如密码匙和密码所采用的保护措施是否适当。
市场上可以找到一系列的自动扫描工具，协助我们进行编码覆检。然而若结合网上应用系统扫描工具，这些工具只能用来确定一般的错误，而不是较复杂的保安问题。因此不应以这些工具取代人的分析。
在任何编码覆检开始之前，项目小组应先定义出编码的哪一部份是属于高风险和可能易受攻击。一般来说，能提供接达控制丶组态管理丶审计丶记录丶授权验证丶提供与第三者或操作系统连结的界面，以上具备这些功能的程式或作业系统，都应接受覆检。这项覆检动作，通常参考 threat modelling或风险评估和设计分析的资料，以决定此项目的哪一个范围应该是编码覆检的一部份。
应用系统推出前阶段
在应用系统推出前和作出重大改动后，应执行资讯科技保安审查。每个修复的保安漏洞都需更新及反映在程式码内，接下来，每一项保安漏洞修复都需要一次程式码更新。因此，要持续维护安全的应用系统，必须评估每项修复所带来的影响。
维修与支援阶段
保安是一持续的过程，保安问题在应用系统推出后仍不断出现。应继续执行保护与侦测的机制，来确保应用系统安全地与顺畅地执行。重要的持续保安措施如下：
应用系统记录的覆检
为了侦测网上应用系统的不正常状况，记录覆检是必要的。许多网络伺服器支援详尽的记录，它们保存了所有在网上应用系统的指令。藉由定期审视网络接达记录和指令，便有可能预见网上应用系统未来的保安问题。一旦发现不正常的划一资源定位（URL），可能代表某种网络攻击已经发生。
此外，应用系统的拥有者也可要求执行网上应用系统的审计追踪，定期查阅那些可疑的指令或显示不正常情况的报表。
版本控制与独立发展环境
维护应用系统的完整性应以适当的保安控制，例如版本控制与各项独立环境供系统发展丶系统测试丶验收测试与现场操作。生产与发展环境应同时进行。发展应用系统的工作人员除了某些必要状况外不可取得生产资讯。
网上应用系统防火墙（Web Application Firewalls, WAF）
标准的防火墙可以限制或允许经过机构授权的接达行为，但在机构的网上应用系统防火墙仍然无从理解其运作中网上应用系统的特定内容。
一般而言网上应用系统防火墙通常安装于网络伺服器之前，这些网上应用系统防火墙的形式如同标准防火墙，可能是软件或硬体，目的是让网络伺服器免受攻击为主。防火墙有两种保护方式：
1.
以辨识码为基础： WAF透过检查网络请求方式，对照攻击辨识码特征档以确定攻击。
2.
以不正常行为作为基础：网上应用系统防火墙透过侦测不正常的传输模式确定攻击。
网上应用系统的验收清单
网上应用系统一经验收后，应执行独立的保安评估来评估网上应用系统和原始码，以确保完全符合公司政策或项目的保安需求。对网上应用系统项目来说，这类评估是必要的且可能会外判至外部人员。保安控制的测试案例，需要在项目的初步阶段实行，且应包含用户验收测试。
应尽早在项目的初步阶段，考虑其保安性。必须与开发人员沟通对保安的期望与需求，特别是授权机制丶数据输入的认证丶与审计追踪。
以下是在评估网上应用程式保安时，需要检视范围的一些例子：
身份识别及认证
1.
使用者与其使用程序如何认证 ?
2.
认证程序是否遵照规格的指示，以及是否遵守机构的保安政策？
3.
如果认证过程是以密码为基础，使用者的密码如何处理与保存？这些密码处理机制，是否符合机构的保安政策？这些密码是写定的密码，或内建于原始程式码中 ?
4.
这些应用系统是否需要在每次连线时针对每一个连结作授权认证？
数据保护
1.
数据保护机制是否符合机构的保安政策？
2.
所有受保护的数据是否经由正确的方式传输？
3.
如果使用加密，如何操作？加密的操作程序是否完全遵照机构的保安政策？
记录
1.
审计追踪记录的机制，是否符合规格？
2.
这些应用系统的审计记录，是否容易受到那些未授权的删除丶修正或泄露？
处理错误
1.
错误讯息是如何被处理？泄漏的数据，有没有可能被后来的攻击行为所利用？应用程式的失败，会导致系统处于危险状态吗？
操作
1.
是否有强制执行职务分工（ Segregation of duties）和最少权限原则？
2.
在启动前，所有的内建使用者身份丶测试的使用者身份丶和预设密码值的身份是否已从作业系统丶网络伺服器及其应用程式本身中移除了？
3.
系统管理程序丶改动管理程序丶运作复原程序丶和备份程序，是否有完整且清楚的界定？
这份清单尚有不足之处，因应保安需求，与网上应用系统目的之特殊性，应根据特殊需求以涵盖额外测试案例或检查标准。
此外，当任何的资讯系统外判给第三方服务提供者时，须执行适当的保安管理程序来保护数据，并减轻资讯科技项目或服务外判时带来的保安风险。建议读者可参阅 "资讯科技服务外判保安"一文得知更多有关外判所需保安考虑的资讯。
给网上应用系统拥有者预防网上攻击的指引
为避免被利用作为网络攻击的跳板，采用保安科技可协助并预防和侦测任何不正常行为。
实施合适的保安事故处理程序是必须的。在许多案例中，通常是第三者如客户，首先发现提供网络服务的网站已经出现问题。在仿冒诈骗中，诈骗网站通常分属不同区域管辖权，真正网站的管理者只能提醒客户注意与原本网站相似的网页，不要去浏览这些诈骗网站。另一个可能的做法就是告知及要求诈骗网站所寄存的网络服务供应商，将此诈骗网站相关连线删除。
研究系统与应用程式中的纪录有助于调查网上攻击事故的行径。本文先前所述之跨网址程式编程攻击蠕虫案例中，受害者的网页只扮演一个将顾客引导到恶性网站的角色，客户电脑里查不到任何攻击者留下的线索。因此，任何可能受害的网页或网站，都必须能够追踪任何跨网站指令攻击的方法，并删除受影响的网页，杜绝更多病毒的感染。
若想让跨网址程式编程攻击成功，攻击者需先将恶意程式植入受害者的网上应用系统。为了预防此事发生，此类恶意访客的输入资料需先经过滤。除了移除输入资料中的特殊字元并将输出作动态编码之外，需建立「白名单」（white-list）法则。在「白名单」法则中，唯有符合先前设定的型态资料才允许进入，其他则全部过滤删除。
对保安事故的侦测与监控丶遏制及预防机制是有必要建立的。应保留系统记录与其他支援资讯，作为提供回溯保安事故时的佐证。为了随时面对更糟的情况，应该建立丶记录并维护关于网站应用系统安全机制的处理与报告程序。
所有员工也应有警觉训练，确保能完全掌控任何保安事故的处理与报告程序
对于任何可疑的系统入侵应立即有跟进行动，且应遵照保安事故处理程序与报告之指引方针。
网上应用系统系统应定期由一群独立丶可靠及可信赖的第三者来评估，以决定网站维持所需最少的控制去遏制可接受的风险。
对保安风险评估的执行也应优先于其他网上应用系统的更新或改变。
另一个可能的预防措施是聘用外部专家去定期检查网上现存的诈骗网站。一旦发现诈骗网站，便可立即通知客户与网站用户，让仿冒诈骗事故降到最低。
相关主题:
参阅资料予:
