Web應用程式安全 許建隆教授兼系主任 長庚大學資訊管理學系 長庚大學資訊管理學系教授兼系主任 中華民國資訊安全學會(CCISA)理事 中華民國資訊安全學會會員委員會主任委員 長庚大學資訊與醫療安全學程召集人(教育部優良學程) 長庚大學RFID物流與供應鏈應用學程召集人 長庚大學資訊安全委員會委員 台灣資通安全研究與教學中心(TWISC)資深研究員 長庚大學健康老化中心研究員 長庚大學銀髮族產業發展與研究中心研究員 ISO 27001主導稽核員

大 綱 前言 Web應用程式安全架構 Web應用程式安全漏洞及OWASP Top 10 Web應用程式安全防護措施 結論

前言

提供Web服務的政府、企業和組織很普遍。但根 據2013年WhiteHat研究報告指出15000個不同產 業網站平均每站有56個嚴重弱點。

資訊安全三要素

資安規範藍圖之發展架構 出處：行政院研究發展考核委員會

資安威脅事件統計我國榜上有名 出處：賽門鐵克

Web應用程式安全架構

運作原理 Web應用程式運作構圖 出處：行政院研究發展考核委員會

Web 應用程式常見的安全架構 防火牆之「網路安全管制」 網頁(Web) 伺服器/應用程式(Application)伺服器/資料庫伺服器之「伺服器 安全管制」 網頁/程式之「Web 應用程式安全管制」

具有安全管制機制之Web應用環境架構 Web應用程式 出處：行政院研究發展考核委員會

Web應用程式安全漏洞

使用者 防火牆 Web應用程式 資料庫 攻擊者 管理者 http https 內部網路 冒用使用者cookie 惡意的輸入參數 偽造釣魚網站 物件參考攻擊 系統命令注入攻擊 XSS、CSRF 不安全的物件參考 Sql注入攻擊

出處：開放Web應用程式安全計畫(OWASP) 2006年CVE揭露弱之分布 CVE : Common Vulnerability Exposures 出處：開放Web應用程式安全計畫(OWASP)

出處：開放Web應用程式安全計畫(OWASP) 歷年CVE揭露數量與弱點分類之比例 根據OWASP在公元2007年公布的TOP 10報告指出，由於網站的配置與設定不 良造成之弱點，遭受攻擊之資安事件占整體的35%。 出處：開放Web應用程式安全計畫(OWASP)

知名攻擊案例 最知名也最嚴重的Web 應用程式攻擊案例子 案例名稱：2005 年7 月所發生轟動一時的美國信用卡代理公司CardSystems 遭駭客入 侵 攻擊方法：駭客就是利用一種普遍的Web 應用程式之漏洞-SQL Injection (SQL 植入式 攻擊)入侵CardSystems 資料庫。 影響：導致2,200 萬張VISA 卡、1,390 萬張萬事達(Master)卡，以及美國運通 (American Express)卡和Discover 卡等逾4,000 萬筆信用卡帳戶資料外洩的事件。導致 這家年營業額超過2,000 萬美元之公司，不但立刻被VISA、Mastercard、American Express 等重要客戶解約，更面臨鉅額之賠償以及美國政府之告訴，最終被PayByouch 購併。

出處：開放Web應用程式安全計畫(OWASP)

OWASP OWASP (Open Web Application Security Project) 是一開放社群、非營利性組織，目前全球有82個分會近萬名會員。 目標為研議協助解決Web軟體安全之標準、工具與技術文件，長期致力於協 助政府與企業了解並改善網頁應用程式與網頁服務之安全性。 美國聯邦貿易委員會(FTC)強烈建議所有企業需遵循OWASP所發佈的十大 Web弱點防護守則、美國國防部亦列為最佳實務，國際信用卡資料安全技術 PCI標準更將其列為必要元件。目前OWASP有30多個進行中的計畫，包括最 知名的OWASP Top 10、安全PHP/Java/ASP.Net等計畫，針對不同的軟體安全 問題在進行討論與研究。

OWASP Local Chapters

OWASP Top 10 (2007) OWASP 統計十大攻擊的比例 We clarified that the Top 10 is about the Top 10 Risks, not the Top 10 most common weaknesses. See the details on the “Application Security Risks” page below. Don’t stop at 10. There are hundreds of issues that could affect the overall security of a web application as discussed in the OWASP Developer’s Guide. This is essential reading for anyone developing web applications today. Guidance on how to effectively find vulnerabilities in web applications are provided in the OWASP Testing Guide and OWASP Code Review Guide, which have both been significantly updated since the previous release of the OWASP Top 10.

出處：開放Web應用程式安全計畫(OWASP) The OWASP Top 10 出處：開放Web應用程式安全計畫(OWASP)

出處：開放Web應用程式安全計畫(OWASP) The OWASP Top 10 出處：開放Web應用程式安全計畫(OWASP)

Risk Rating Methodology The OWASP Risk Rating Methodology Discovering vulnerabilities is important, but just as important is being able to estimate the associated risk to the business. Early in the lifecycle, you may identify security concerns in the architecture or design by using threat modeling. Later, you may find security issues using code review or penetration testing. Or you may not discover a problem until the application is in production and is actually compromised. By following the approach here, you'll be able to estimate the severity of all of these risks to your business, and make an informed decision about what to do about them. Having a system in place for rating risks will save time and eliminate arguing about priorities. This system will help to ensure that you don't get distracted by minor risks while ignoring more serious risks that are less well understood. Ideally, there would be a universal risk rating system that would accurately estimate all risks for all organizations. But a vulnerability that is critical to one organization may not be very important to another. So a basic framework is presented here that you should customize for your organization. The authors have tried hard to make this model simple enough to use, while keeping enough detail for accurate risk estimates to be made. Please reference the section below on customization for more information about tailoring the model for use in your organization. Approach There are many different approaches to risk analysis. See the reference section below for some of the most common ones. The OWASP approach presented here is based on these standard methodologies and is customized for application security. Let's start with the standard risk model: Risk = Likelihood * Impact In the sections below, we break down the factors that make up "likelihood" and "impact" for application security and show how to combine them to determine the overall severity for the risk. #Step 1: Identifying a Risk #Step 2: Factors for Estimating Likelihood #Step 3: Factors for Estimating Impact #Step 4: Determining Severity of the Risk #Step 5: Deciding What to Fix #Step 6: Customizing Your Risk Rating Model Step 1: Identifying a Risk The first step is to identify a security risk that needs to be rated. You'll need to gather information about the threat agent involved, the attack they're using, the vulnerability involved, and the impact of a successful exploit on your business. There may be multiple possible groups of attackers, or even multiple possible business impacts. In general, it's best to err on the side of caution by using the worst-case option, as that will result in the highest overall risk. Step 2: Factors for Estimating Likelihood Once you've identified a potential risk, and want to figure out how serious it is, the first step is to estimate the "likelihood". At the highest level, this is a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker. We do not need to be over-precise in this estimate. Generally, identifying whether the likelihood is low, medium, or high is sufficient. There are a number of factors that can help us figure this out. The first set of factors are related to the threat agent involved. The goal is to estimate the likelihood of a successful attack from a group of possible attackers. Note that there may be multiple threat agents that can exploit a particular vulnerability, so it's usually best to use the worst-case scenario. For example, an insider may be a much more likely attacker than an anonymous outsider - but it depends on a number of factors. Note that each factor has a set of options, and each option has a likelihood rating from 0 to 9 associated with it. We'll use these numbers later to estimate the overall likelihood. Threat Agent Factors The first set of factors are related to the threat agent involved. The goal here is to estimate the likelihood of a successful attack by this group of threat agents. Use the worst-case threat agent. Skill level How technically skilled is this group of threat agents? Security penetration skills (9), network and programming skills (6), advanced computer user (4), some technical skills (3), no technical skills (1) Motive How motivated is this group of threat agents to find and exploit this vulnerability? Low or no reward (1), possible reward (4), high reward (9) Opportunity What resources and opportunity are required for this group of threat agents to find and exploit this vulnerability? full access or expensive resources required (0), special access or resources required (4), some access or resources required (7), no access or resources required (9) Size How large is this group of threat agents? Developers (2), system administrators (2), intranet users (4), partners (5), authenticated users (6), anonymous Internet users (9) Vulnerability Factors The next set of factors are related to the vulnerability involved. The goal here is to estimate the likelihood of the particular vulnerability involved being discovered and exploited. Assume the threat agent selected above. Ease of discovery How easy is it for this group of threat agents to discover this vulnerability? Practically impossible (1), difficult (3), easy (7), automated tools available (9) Ease of exploit How easy is it for this group of threat agents to actually exploit this vulnerability? Theoretical (1), difficult (3), easy (5), automated tools available (9) Awareness How well known is this vulnerability to this group of threat agents? Unknown (1), hidden (4), obvious (6), public knowledge (9) Intrusion detection How likely is an exploit to be detected? Active detection in application (1), logged and reviewed (3), logged without review (8), not logged (9) Step 3: Factors for Estimating Impact When considering the impact of a successful attack, it's important to realize that there are two kinds of impacts. The first is the "technical impact" on the application, the data it uses, and the functions it provides. The other is the "business impact" on the business and company operating the application. Ultimately, the business impact is more important. However, you may not have access to all the information required to figure out the business consequences of a successful exploit. In this case, providing as much detail about the technical risk will enable the appropriate business representative to make a decision about the business risk. Again, each factor has a set of options, and each option has an impact rating from 0 to 9 associated with it. We'll use these numbers later to estimate the overall impact. Technical Impact Factors Technical impact can be broken down into factors aligned with the traditional security areas of concern: confidentiality, integrity, availability, and accountability. The goal is to estimate the magnitude of the impact on the system if the vulnerability were to be exploited. Loss of confidentiality How much data could be disclosed and how sensitive is it? Minimal non-sensitive data disclosed (2), minimal critical data disclosed (6), extensive non-sensitive data disclosed (6), extensive critical data disclosed (7), all data disclosed (9) Loss of integrity How much data could be corrupted and how damaged is it? Minimal slightly corrupt data (1), minimal seriously corrupt data (3), extensive slightly corrupt data (5), extensive seriously corrupt data (7), all data totally corrupt (9) Loss of availability How much service could be lost and how vital is it? Minimal secondary services interrupted (1), minimal primary services interrupted (5), extensive secondary services interrupted (5), extensive primary services interrupted (7), all services completely lost (9) Loss of accountability Are the threat agents' actions traceable to an individual? Fully traceable (1), possibly traceable (7), completely anonymous (9) Business Impact Factors The business impact stems from the technical impact, but requires a deep understanding of what is important to the company running the application. In general, you should be aiming to support your risks with business impact, particularly if your audience is executive level. The business risk is what justifies investment in fixing security problems. Many companies have an asset classification guide and/or a business impact reference to help formalize what is important to their business. These standards can help you focus on what's truly important for security. If these aren't available, then talk with people who understand the business to get their take on what's important. The factors below are common areas for many businesses, but this area is even more unique to a company than the factors related to threat agent, vulnerability, and technical impact. Financial damage How much financial damage will result from an exploit? Less than the cost to fix the vulnerability (1), minor effect on annual profit (3), significant effect on annual profit (7), bankruptcy (9) Reputation damage Would an exploit result in reputation damage that would harm the business? Minimal damage (1), Loss of major accounts (4), loss of goodwill (5), brand damage (9) Non-compliance How much exposure does non-compliance introduce? Minor violation (2), clear violation (5), high profile violation (7) Privacy violation How much personally identifiable information could be disclosed? One individual (3), hundreds of people (5), thousands of people (7), millions of people (9) Step 4: Determining the Severity of the Risk In this step we're going to put together the likelihood estimate and the impact estimate to calculate an overall severity for this risk. All you need to do here is figure out whether the likelihood is LOW, MEDIUM, or HIGH and then do the same for impact. We'll just split our 0 to 9 scale into three parts. Likelihood and Impact Levels 0 to <3 LOW 3 to <6 MEDIUM 6 to 9 HIGH Informal Method In many environments, there is nothing wrong with "eyeballing" the factors and simply capturing the answers. You should think through the factors and identify the key "driving" factors that are controlling the result. You may discover that your initial impression was wrong by considering aspects of the risk that weren't obvious. Repeatable Method If you need to defend your ratings or make them repeatable, then you may want to go through a more formal process of rating the factors and calculating the result. Remember that there is quite a lot of uncertainty in these estimates, and that these factors are intended to help you arrive at a sensible result. This process can be supported by automated tools to make the calculation easier. The first step is to select one of the options associated with each factor and enter the associated number in the table. Then you simply take the average of the scores to calculate the overall likelihood. For example: Threat agent factors Vulnerability factors Skill level Motive Opportunity Size Ease of discovery Ease of exploit Awareness Intrusion detection 5 2 7 1 3 6 9 2 Overall likelihood=4.375 (MEDIUM) Next, we need to figure out the overall impact. The process is similar here. In many cases the answer will be obvious, but you can make an estimate based on the factors, or you can average the scores for each of the factors. Again, less than 3 is LOW, 3 to less than 6 is MEDIUM, and 6 to 9 is HIGH. For example: Technical Impact Business Impact Loss of confidentiality Loss of integrity Loss of availability Loss of accountability Financial damage Reputation damage Non-compliance Privacy violation 9 7 5 8 1 2 1 5 Overall technical impact=7.25 (HIGH) Overall business impact=2.25 (LOW) Determining Severity However we arrived at the likelihood and impact estimates, we can now combine them to get a final severity rating for this risk. Note that if you have good business impact information, you should use that instead of the technical impact information. But if you have no information about the business, then technical impact is the next best thing. Overall Risk Severity Impact HIGH Medium High Critical MEDIUM Low Medium High LOW Note Low Medium   LOW MEDIUM HIGH   Likelihood In the example above, the likelihood is MEDIUM, and the technical impact is HIGH, so from a purely technical perspective, it appears that the overall severity is HIGH. However, note that the business impact is actually LOW, so the overall severity is best described as LOW as well. This is why understanding the business context of the vulnerabilities you are evaluating is so critical to making good risk decisions. Failure to understand this context can lead to the lack of trust between the business and security teams that is present in many organizations. Step 5: Deciding What to Fix After you've classified the risks to your application, you'll have a prioritized list of what to fix. As a general rule, you should fix the most severe risks first. It simply doesn't help your overall risk profile to fix less important risks, even if they're easy or cheap to fix. Remember, not all risks are worth fixing, and some loss is not only expected, but justifiable based upon the cost of fixing the issue. For example, if it would cost $100,000 to implement controls to stem $2,000 of fraud per year, it would take 50 years return on investment to stamp out the loss. But remember there may be reputation damage from the fraud that could cost the organization much more. Step 6: Customizing Your Risk Rating Model Having a risk ranking framework that's customizable for a business is critical for adoption. A tailored model is much more likely to produce results that match people's perceptions about what is a serious risk. You can waste lots of time arguing about the risk ratings if they're not supported by a model like this. There are several ways to tailor this model for your organization. Adding factors You can choose different factors that better represent what's important for your organization. For example, a military application might add impact factors related to loss of human life or classified information. You might also add likelihood factors, such as the window of opportunity for an attacker or encryption algorithm strength. Customizing options There are some sample options associated with each factor, but the model will be much more effective if you customize these options to your business. For example, use the names of the different teams and your names for different classifications of information. You can also change the scores associated with the options. The best way to identify the right scores is to compare the ratings produced by the model with ratings produced by a team of experts. You can tune the model by carefully adjusting the scores to match. Weighting factors The model above assumes that all the factors are equally important. You can weight the factors to emphasize the factors that are more significant for your business. This makes the model a bit more complex, as you'll need to use a weighted average. But otherwise everything works the same. Again, you can tune the model by matching it against risk ratings you agree are accurate. References Managing Information Security Risk: Organization, Mission, and Information System View [1] Industry standard vulnerability severity and risk rankings (CVSS) [2] Security-enhancing process models (CLASP) [3] Cheat Sheet: Web Application Security Frame - MSDN - Microsoft [4] Threat Risk Modeling Pratical Threat Analysis [5] Application Security Risk Assessment Guidelines [6] A Platform for Risk Analysis of Security Critical Systems [7] Model-driven Development and Analysis of Secure Information Systems [8] Value Driven Security Threat Modeling Based on Attack Path Analysis [9]

OWASP 2013 TOP 10

A1 – Injection Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. Ex: SQL Injection Attack

A2 – Broken Authentication and Session Management Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities. Examples

A3 – Cross-Site Scripting (XSS) XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. Examples

A4 – Insecure Direct Object References A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data. Examples

A5 – Security Misconfiguration Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application. Examples

A6 – Sensitive Data Exposure (2010-A7-Merge Insecure Cryptographic Storage and 2010-A9-Insufficient Transport Layer Protection) Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser. Insecure Cryptographic Storage Insufficient Transport Layer Protection Insecure Communication Information Leakage and Improper Error Handling

A7 – Missing Function Level Access Control (2010-A8-Failure to Restrict URL Access) Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization. Failure to Restrict URL Access Malicious File Execution

A8 – Cross-Site Request Forgery (CSRF) A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim. Cross-Site Request Forgery

Security Misconfiguration A9 – Using Components with Known Vulnerabilities (was mentioned as part of 2010-A6-Security Misconfiguration) Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts. Security Misconfiguration

A10 – Unvalidated Redirects and Forwards Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages. Unvalidated Redirects and Forwards

Web應用程式安全 防護措施

Web應用程式開發流程 出處：行政院研究發展考核委員會

修正漏洞所需之相對成本 出處：行政院研究發展考核委員會

安全管控程序 出處：行政院研究發展考核委員會

出處：行政院研究發展考核委員會

Web應用程式安全檢核方式 原始碼檢測 在應用程式正式上線前，運用原始碼檢測工具檢核程式碼弱點，可避免弱點暴露，效果 較弱點掃描方式佳。此方式建議採自動化掃描工具，以人工檢核方式效率較差，且容易 遺漏。 網頁應用程式弱點掃描 如單位無原始碼檢測工具，可使用網頁弱點掃描工具，定期稽核網頁應用程式弱點，檢 核深度較原始碼檢測方式差。此方式為採自動化掃描工具。 外部滲透測試 滲透測試可以黑箱測試模式進行，並嘗試以單點突破，可檢驗網站是否存在潛在弱點。 此方式多以人工方式進行，測試過程極為耗時。

Web應用程式安全檢核方式 傳統外部檢測：入侵滲透測試(Penetration Test, 簡稱PT)。 高漏報率 低精確性 人工源碼檢測：白箱(White-box)測試 降低黑箱測試的漏報率與精確度 費用驚人 自動源碼檢測：軟體驗證(白箱)和滲透測試(黑箱) 高涵蓋率 高正確性 高精確度 發現薄弱安全環節的精確位置(在源碼的那一行)。 追蹤問題源碼的函式從屬關係。 針對問題源碼提出修正建議。

源碼檢測技術 出處：行政院研究發展考核委員會

源碼檢測四步驟 步驟1 資安目標、需求分析 步驟2 源碼驗證搭配弱點清單 步驟3 源碼驗證搭配設定管理 步驟4 網路安全、伺服器安全 確認資安目標，瞭解用戶需求，才能明確定義檢查過程欲達到的目標與瞭解檢測的限 制。 步驟2 源碼驗證搭配弱點清單 執行初步掃瞄：使用自動靜態分析找出初步的一組錯誤集合，儘量在開發階段就修正 此錯誤。 步驟3 源碼驗證搭配設定管理 針對整合後的系統進行源碼檢查：可以集中針對步驟2 的結果來進行分析與改善或全 面的檢測常見資安弱點。 步驟4 網路安全、伺服器安全 網路架構暨伺服器檢查：完成最後系統部署後，應搭配網路層安全，譬如網路層防火 牆，以及應用層安全的防護，譬如Web 應用程式防火牆。假如要完成一個完整的資 安防護架構，那麼網路層面、系統層面，以及程式運作面都需要相互搭配協防。

Web 應用程式之源碼檢測所涵蓋的資安弱點分類 出處：行政院研究發展考核委員會

OWASP Application Security Verification Standard (ASVS) 目的：提供可行的、公開的商業化安全標準。 以自動化工具協助ASVS的高等級。 但不同的App和framework仍應適當調整工具。 ASVS等級 1 2 3 4 自動化工具 人工源碼和測試驗證 人工驗證 設計 惡意程式碼 Open web application security project(OWASP)是一個全球性的公開社群組織，目的在於增進網路安全的透明度，讓一般人和政府能根據實際的應用程式安全風險制定決策。OWASP免費提供資安工具、說明文件和書籍，努力保持其免費資源的中立性且不偏頗於特定廠商。2007和2010曾提出 OWASP Top10 獲得美國政府、國際信用卡組織參考。 2009年，OWASP提出Application security verification standard(ASVS)，又稱為應用程式安全驗證標準，目的是提供一致的、中立的驗證指標用以分辨不同的WEB安全檢測產品。另一方面，也可用來建立WEB應用程式的資安信任等級。ASVS標準分為四個等級如表，等級越高所需要滿足的檢測要求越多，檢測方法越仔細，檢測範圍越廣、檢測方法越嚴謹。

OWASP ASVS 整合SDLC 設定計畫，如何達到您根據ASVS而訂立的標準 檢測應用程式的弱點 檢驗應用程式是否滿足ASVS安全等級 . 設定計畫，如何達到您根據ASVS而訂立的標準 檢測應用程式的弱點 檢驗應用程式是否滿足ASVS安全等級 參考OWASP ESAPI，達到ASVS的要求 以風險等級定義需求 依照風險等級設計系統 實作系統 執行初次驗證 修正後重新驗證 修正弱點 再一次循環驗證 實作企業控制項並整合到您的標準控制項 定義您的標準，並對應ASVS等級的需求 黃框的部分是ASVS可以應用到Web應用程式的開發周期。 ASVS可以設定協助應用程式設定安全等級，並依照ASVS的檢測項目規劃企業的安全控制項。 實作控制項之後，再一次依照ASVS的檢測項目檢測應用程式的弱點。

OWASP ASVS 分級檢測 等級 檢測方法 檢測要求和項目 等級一 自動化檢驗 一A、自動化動態掃描 將Web應用程式當作單一物件，以自動化工具執行檢測，並以人工校對結果，須符合24項檢測要求。 一B、自動化程式碼掃描 等級二 人工檢驗 二A、人工安全測試 除了包含等級一的檢測方法與範圍，還要將Web應用程式分為控制邏輯層、UI層、業務功能和資料層，以人工方式檢測91項要求。 二B、人工程式碼檢測 等級三 設計檢驗 人工檢視系統設計 等級二加上檢驗威脅模擬資訊(例如DREAD)是否符合系統設計圖。 以人工方式驗證108項檢測要求。 等級四 內部檢驗 人工檢測惡意程式碼 等級三加上檢測應用程式中所有的惡意程式碼(泛指避開或違反Web應用程式安全政策的程式碼)。並以人工方式驗證121項檢測要求。 14種類121項要求 V1. 安全架構文件 V2. ~V14. 安全控制項要求 檢測方法有包括 a.以自動化工具為主的靜態原始碼分析、動態網站掃描； 靜態原始碼分析可以準確找出某些漏洞並提供修改建議，但無法找出只發生在網站動態執行階段的漏洞； 動態網站掃描可以找到網站執行階段的漏洞，但開發者須花時間分析實際的發生點； b.以真實攻擊手法為主的人工滲透測試和人工原始碼檢查。 雇用資安專家進行人工滲透測試可以找出網站程式的邏輯漏洞、業務流程的瑕疵，但執行成本高。 c.和d.也是以人工方式檢驗威脅模擬資訊是否符合系統設計

OWASP ASVS 檢測項目 安全要求 項目 V1.建立安全架構的文件(Security Architecture) 6 V2.身分認證(Authentication) 15 V3.Session 管理機制(Session Management) 13 V4.存取控制(Access Control) V5.輸入資料驗證(Input Validation) 9 V6.輸出內容編碼(Output Encoding/Escaping) 10 V7.密碼學(Cryptography) V8.錯誤訊息管理和紀錄(Error Handling and Logging) 12 V9.資料保護(Date Protection) V10.通訊安全(Communication Security) V11.HTTP 安全(HTTP Security) 7 V12.環境設定(Security Configeration) 4 V13.惡意程式碼的搜尋(Malicious Code Search) 2 V14.內部安全(Internal Security) 3 V1.建立安全架構的文件(Security Architecture) 安全架構文件應包含WEB應用程式中的所有原始碼、函式庫、執行檔、元件各類資源的位置與功能。檢測結果可依照架構文件追蹤弱點的位置與功能。 V2.身分認證(Authentication) 妥善控管認證的流程與機敏資訊，除了公開資源以外，所有頁面和資源都須經過身分認證才能存取；所有機敏資訊不能顯示在網頁上；身分認證的管理機制與密碼強度要能抵抗暴力破解法。即使已經登入，執行特殊功能或存取機敏資訊須再次身分認證。 V3. Session 管理機制 經過登出、閒置一段時間、重新登入後，Session id應更新；保護合法的Session不被攻擊者竊取冒用合法使用者。 V4.存取控制(Access Control) 使用者只能依照權限存取系統功能、URL、檔案；存取控制措施應實作在伺服器端，並留下存取記錄以供稽核。 V5.輸入資料驗證(Input Validation) 所有輸入資料(包含POST表單、GET參數、WEB SERVICE、各項協定的COMMAND)都應採用白名單過濾規則驗證只包含合法字元；驗證失敗後的資料應消毒後再返回給使用者；輸入驗證措施應實作在伺服器端，並留下驗證失敗的記錄以供稽核。 V6.輸出內容編碼(Output Encoding/Escaping) 所有輸出資料應適當編碼或使用參數化界面(Parameterized Interface)再輸出到外部應用程式，例如：SQL 查詢句輸出到DBMS。 V7.密碼學(Cryptography) 應用程式的加密方法、金鑰管理、亂數、雜湊運算應採用安全且公開的演算法，可參考FIPS 140-2；用以保護機敏資訊的加解密功能應實作在伺服器端，加解密失敗應記錄被查；產生使用者密碼的雜湊值應加入salt。 V8.錯誤訊息管理和紀錄(Error Handling and Logging) 紀錄錯誤訊息可分析資安事件和攻擊行為的特徵，但不能包含使用者機敏資料；伺服器端的預設錯誤訊息能讓使用者得知進一步資訊，應改為輸出自訂的錯誤訊息，並將詳細錯誤內容儲存到紀錄檔。 V9.資料保護(Date Protection) 機敏資料不能存放在客戶端的快取，不能啟用自動完成功能；存放在 Server 端的敏感資料的複本，不論快取或暫存，不能被無權的他人存取，且合法使用者存取之後應該刪除。 V10.通訊安全(Communication Security) 確保可信任憑證中心(Trusted CA)和 TLS 憑證之間的路徑暢通，且憑證是有效的；登入或使用重要功能都應使用TLS。 V11.HTTP 安全(HTTP Security) Http請求和回應只能包含安全的、可顯示的ASCII字元。存放於客戶端的cookie應加上HTTPOnly而不能被Javascript存取。 V12.環境設定(Security Configeration) 保護安全設定的檔案(例如；NET平台的Security.config)，應拒絕非法存取。 V13.惡意程式碼的搜尋(Malicious Code Search) 惡意程式碼泛指用以避開Web應用程式安全政策的程式碼。 V14.內部安全(Internal Security) 確保應用程式中擁有自我驗證保護，避免內部開發人員的實作缺失或是邏輯炸彈。

NIST FIPS-199和FIPS-200 目的 FIPS-199提供一套資訊系統分類標準，依據聯邦單位 擁有或維護的資訊系統和資訊其風險等級的範圍決定 安全等級。 FIPS-199資訊系統的分級參考指引。 FIPS-200各安全等級的最低安全要求。 資安三大目標：機密性(Confidentiality)、真確性 (Integrity)和可用性(Availability)。 三大目標又各分為三個等級的影響衝擊程度。 十七類安全要求。 2006年，NIST公布FIPS的199號和200號規範。希望建立更一致的、可比較的、可重複的方法讓聯邦單位選擇資訊系統的安全控制項，依照不同等級滿足最低安全要求。

NIST FIPS-199和FIPS-200(2) 潛在影響衝擊的分析表 目標 影響衝擊低 影響衝擊中 影響衝擊高 機密性 預估未經授權的資訊洩漏會造成組織營運、財產或個人有限的負面影響。 未經授權的資訊洩漏造成造成組織營運、財產或個人嚴重的負面影響。 未經授權的資訊洩漏造成組織營運、財產或個人不可復原的負面影響。 完整性 未經授權的修改或刪除資訊造成組織營運、財產或個人有限的負面影響。 未經授權的修改或刪除資訊造成組織營運、財產或個人嚴重的負面影響。 未經授權的修改或刪除資訊造成組織營運、財產或個人不可復原的負面影響。 可用性 存取資訊系統遭到中斷造成組織營運、財產或個人有限的負面影響。 存取資訊系統遭到中斷造成組織營運、財產或個人嚴重的負面影響。 存取資訊系統遭到中斷造成組織營運、財產或個人不可復原的負面影響。 機密性(Confidentiality)、真確性(Integrity)和可用性(Availability)資安三大目標[4]的角度評估影響程度為低、中或高。 機密性的損失代表未授權的資訊洩漏。真確性的損失代表資訊被未授權的修改或刪除。可用性的損失代表使用資訊系統被中斷。

NIST FIPS-199和FIPS-200(3) 類別 17類安全要求 項目 管理面 Risk assessment 4 Planning 5 System and services acquisition  16 Certification, accreditation, and security assessments  6 作業面 Personnel security  8 Physical and environmental protection  19  Contingency planning  12 Configuration management  11 Maintenance  System and informational integrity  13 Media protection  Incident response  9 Awareness and training  技術面 Identification and authentication  Access control  22 Audit and accountability  System and communications protection  41 RA風險評估 ：評估組織營運流程(任務、功能、形象)、資產、個人的風險 PL計畫：組織必須發展、記錄、定期更新和實作安全計畫。 SA系統和服務採購：i組織並須收集足夠資表戶組織資訊系統 ii系統開發時必要將安全性列入考量 iii實施軟體安裝限制 iv 確保第三方供應商有足夠資源保護資訊系統 PS個人安全：i組織必須確保員工式值得信賴的 ii 即使系統或資訊被員工惡意中止或傳輸，仍處於保護措施之內 iii 制裁違反規定的員工 PE實體與環境保護：i限制只有少數特權能實體存取系統硬體 CP偶發事件計畫：組織必須有偶發重大事件的緊急反應措施、備援機制、災難復原計畫。 MA維護：組織必須 i定期維護系統 ii 提供足夠的工具、技術和人力去維護系統 SI系統與資訊真確性：組織必須 i 定時鑑定、報告和更正系統缺失

NIST FIPS-199和FIPS-200(4) 根據管理面、作業面、技術面的最低安全需求，評量不同等級資訊系統 判定機密性、完整性、可用性的潛在影響衝擊 以潛在影響衝擊最高者為安全等級 根據管理面、作業面、技術面的最低安全需求，評量不同等級資訊系統

WEB威脅和安全標準的關係 OWASP TOP 10 FIPS-199安全控制項 ASVS安全控制項 注入攻擊 無 V5輸入資料驗證 失效的驗證與連線管理 存取控制(AC) V4存取控制 V3連線管理機制 跨站腳本攻擊 V6輸出內容編碼 不安全的物件參考 V11 HTTP 安全 不當安全組態設定 系統和通訊保護(SC) V8錯誤訊息管理和紀錄 V12環境設定 敏感資料暴露 個人保護(PS) V7密碼機制 V10通訊安全 缺少功能級別的存取控制 身分鑑別和驗證(IA) V2身分鑑別 跨站請求偽造 V11 HTTP安全 使用已知漏洞元件 未驗證的重新導向和轉送 實務上，Web應用程式是屬於資訊系統的一種實作部署方式，根據FIPS-199安全等級，聯邦資訊系統需滿足十七類安全要求以保障機密性、完整性和可用性。但對於應用層的WEB威脅，例如OWASP Top 10 Web應用程式風險[14]、 SANS Top 25 危險的軟體錯誤[15]，並無具體應對規範。故並無法完全符合實務上Web應用程式安全檢測的需求，這部分反而不及OWASP所提出的ASVS規範更符合WEB應用程式安全實務。經本研究整理的以OWASP top10、FIPS 199 和 ASVS比較如下表。

結論 Web應用程式安全的漏洞日新月異 Web應用程式安全的防護機制必須持續改善 個人資料保護法的通過，將影響Web應用程式安全的重要性

Thanks for Your Attention! Q&A

SQL Injection Attack

SQL Injection攻擊簡介 SQL Injection 稱為SQL 指令植入式攻擊，主要是屬於Input Validation 的問題。目前被翻譯成『資料隱碼』攻擊。 SQL Injection攻擊法並非植入電腦病毒，它是描述一個利用寫入特殊SQL程式碼攻擊應用程式的動作。換言之，只要提供給使用者輸入的介面，又沒有做到相當嚴密的輸入資料型態管制，就有可能會遭受這種行為的攻擊。 攻擊者在網頁應用程式提供的介面上輸入精心設計的SQL字串資料，來改變程式預期要執行的SQL 語法。

SQL Injection攻擊簡介 帳號/密碼 SQL指令 夾雜其中

SQL Injection攻擊原理 一般登入網站的SQL語法 select * from user where UID =‘ “& request(”UID“) &"' And Passwd=' "& request("Passwd") & "‘ 如果正常使用者帳號:jacky ，密碼:1234 select * from user where UID =‘jacky’ And Passwd='1234 select * from user where UID =‘ “& request(“UID”) &”’ And Passwd=' "& request("Passwd") & "‘ 若攻擊者已知系統中已有一個Admin的管理者帳號，則輸入Admin‘/*，即可輸入任意密碼而進入資料庫 select * from user where UID =' Admin'/*' and Passwd=' ‘ 註: /*符號後的任何敘述都會被當作註解

select * from member where SQL Injection攻擊原理(1/3) 駭 客 select * from member where UID =‘admin‘-- And PWD='1234' ID = admin’-- PWD = 1234 Firewall Web Server DB Server Web Server

SQL Injection攻擊原理(2/3) UserName = john Pass = 123abc 惡意輸入 登入網頁的部份程式碼 … <% If Request("UserName")<>"" And Request("Pass")<>"" Then Dim cnn,rec,strSQL Set cnn=Server.CreateObject("ADODB.Connection") With cnn .ConnectionString=Application("Conn") .Open ‘依據使用者輸入的資料來組合 SQL 語法 strSQL="SELECT * FROM tblUser WHERE UserName='" & _ Request("UserName") & "' AND Password='" & Request("Pass") & "'" ‘傳送給 SQL Server 執行，如此會有SQL Injection問題 Set rec=.Execute(strSQL) End With If NOT rec.EOF Then Session("UserName")=Request("UserName") Response.Write "歡迎光臨 " & Request("UserName") Else Response.Write "您的帳號/密碼輸入錯誤" End If %> SELECT * FROM tblUser WHERE UserName=‘john’ AND Password=‘123abc’ 正常輸入 UserName = john Pass = 123abc 惡意輸入 UserName = admin’-- Pass = 1234 SELECT * FROM tblUser WHERE UserName='admin'--' AND Password='asdf'

SQL Injection攻擊原理(3/3) 停掉 SQL Server 的執行 破壞整個資料庫的內容 刪除資料庫內某個資料表： 字串: ' or " 單行註解: -- or # 多行註解: /*…*/ 連結,結合,或空白: + 結合: || 萬用字元: % URL參數: ?Param1=foo&Param2=bar 指令: PRINT 區域變數: @variable 全域變數: @@variable 停掉 SQL Server 的執行 ' ;SHUTDOWN— 破壞整個資料庫的內容 ' ;DROP Database <資料庫名稱>-- 刪除資料庫內某個資料表： ' ;DROP Table <資料表名稱>-- 清空資料表中所有欄位的值： ' ;Truncate Table <資料表名稱>-- 清空資料表： ' ;DELETE FROM <資料表名稱>--

SQL Injection攻擊的影響 執行多個SQL 語法 存取及控制資料庫中的內容 繞過身份驗證機制 影響的系統包括MSSQL、MySQL、Oracle、Sybase、DB2及MS Access等。 SQL Injection問題 不是使用何種平台或是程式語言的問題 而是一種檢驗機制的問題

SQL Injection攻擊案例1 在網頁欄位中，輸入含有SQL指令的資訊，逃避掉程式的驗證機制。 SQL指令 夾雜其中

SQL Injection攻擊案例2 從網址列進行SQL Injection攻擊 http://localhost/test.asp?username=username&password=password 改用以下方法連結 http://localhost/test.asp?username=‘or1=1--&password=‘or1=1-- ※從瀏覽器中「檢視原始碼」，得知使用者與密碼欄位的確實名稱※

SQL Injection攻擊案例3 使用URL編碼進行SQL Injection攻擊 利用不同的編碼來通過開發人員的過濾機制。 轉換「’」或「；」為ASCII code 或Unicode避開過濾機制。 「’」－＞ASCII code = 39 , Unicode = %27 http://localhost/test.asp?username=or%27a%27=%27a%27&password=123 等於 http://localhost/test.asp?username=or’a’=‘a’&password=123

Demo Hack pass website Hacking_into_websites_SQL_injection_demo OWASP Mantra - Broken Authentication_By Pass Client SQL Injection Prevention OWASP Top 10 2010_ A7 - Inection and Insecure Cryptographic Storage SQL Injection Explained How to find lots of SQL vulnerable sites Web Server Attacks Demo

Broken Authentication and Session Management

Broken Authentication and Session Management （身分驗證功能缺失） Web應用程式中自行撰寫的身分驗證相關功能有缺陷 例如，登入時無加密、SESSION 無控管、Cookie 未保護、密碼強度過弱等 等

Broken Authentication and Session Management (Cont.) 所有的密碼、Session ID、以及其他資訊都有透 過加密傳輸嗎？ 憑證都有經過加密或hash保護嗎？ 驗證資訊能被猜測到或被其他弱點修改嗎 Session ID 是否在 URL 中暴露出來？ Session ID 是否有 Timeout 機制？

Prevention 使用完善的 COOKIE / SESSION 保護機制 不允許外部 SESSION 登入及修改資訊頁面使用 SSL 加密 設定完善的 Timeout 機制 驗證密碼強度及密碼更換機制

Session 保護檢查 Client IP 位址 Browser User-Agent Timestamp Unique ID DEMO PHP SESSION CHECK

Session 檢查 PHP session.use_trans_sid=0 JSP sessionid from cookie <%= request.isRequestedSessionIdFromCookie() %> JSP sessionid from url <%= request.isRequestedSessionIdFromURL() %> session.use_trans_sid=0 表示伺服器禁止將使用者的sesseion_id附加在網址後面。 request.isRequestedSessionIdFromCookie 如果session id是通过客户端的一个cookie提供的，則為真 request.isRequestedSessionIdFromURL 如果session id是通过客戶端一部分URL提供的，則為真

Session ID http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSND LPSKHCJUN2JV?dest=Hawaii SESSION ID 在 URL 直接暴露

SESSION Timeout 應用程式 SESSION Timeout 沒有設定。使用者 在使用公用電腦登入後卻沒有登出，只是關閉視 窗。攻擊者在經過一段時間之後使用同一台電腦， 卻可以直接登入。

認證未走 SSL / TLS 加密 網站並沒有使用 SSL / TLS 加密，使用者在使用 一般網路或者無線網路時，被攻擊者使用 Sniffer 竊聽取得 User ID、密碼、SESSION ID 等，進一 步登入該帳號。

Demo Lab CGU Login OWASP Mantra - Broken Authentication OWASP Mantra - Broken Session Management

Cross Site Scripting (XSS)

Cross Site Scripting攻擊簡介 定義： XSS 跨網站腳本攻擊是指攻擊者在未經授權的情況下擅自將惡意程式碼注入 到網站上。 XSS攻擊是利用動態網頁的特性、程式開發者未嚴格限制使用者輸入與未過濾特殊字串，讓惡意的Script得以在使用者的瀏覽器上執行 可用的Script包含： JavaScript、VBScript XSS與SQL Injection相同，都是駭客的填空遊戲。

Cross Site Scripting攻擊簡介 正常畫面： http://victim/index.php?act=product&CategoryID=887 攻擊畫面： http://victim/index.php?act=product<script>alert(/XSS/)</script>&CategoryID=887

XSS攻擊的影響 符合下列條件的網頁都可能受到影響 網頁參數未執行檢查 允許使用者上傳網頁、影音資料檔等，如 YouTube網站 網頁應用程式 ASP、PHP、JSP、CSS、XML、AJAX… 能使用Script的物件 Realplayer、Quicktime、Mediaplayer、Flash…

常見XSS攻擊模式 輕微的XSS攻擊- 惡作劇 嘗試破壞網頁畫面配置和內容 惡作劇程式、顯示討厭的訊息、廣告視窗等 主要影響是造成使用者的不便 嚴重的XSS攻擊- 竊取資料 盜取連線資訊：cookie、帳號密碼 網路釣魚：置換登入頁面，騙取使用者帳號密碼 惡意程式：瀏覽即下載惡意程式、竊取個人資訊

XSS攻擊案例1 國外的著名案例- Netscape.com 一名使用者曾多次警告Netscape公司其網站具有XSS弱點，但Netscape公司置之不理，該使用者便在其網頁中進行下列攻擊  於該網頁中顯示警告視窗  將連線導向 http://www.Digg.com/

XSS攻擊案例1

XSS攻擊案例2 國外的著名案例- MySpace 19歲的程式設計師Samy在自己的個人簡介上放了XSS蠕蟲，每個瀏覽他簡介的人都會被一段JavaScript自動加入為Samy的好友，該蠕蟲會自動複製到受害者的個人簡介中，把惡意JavaScript也複製進去，故查看受害者的個人簡介時，也會被感染，Samy藉此在24小時內感染了1,000,000 MySpace會員 19歲的「Samy」跟自己女友打賭他可以在MySpace上擁有很多粉絲，將他設成英雄（Hero），但是又達不到，才突然想到不如寫隻程式作弊好了，他就編寫了一段Script，使他獲得了超過100萬個「好友」。他在自己的MySpace簡介裡，置入一段JavaScript代碼，這樣每個查看簡介的人會在不知不覺中執行這段代碼。這段代碼把他列為該用戶的好友之一。接著，該蠕蟲會打開該用戶自己的簡介，把惡意代碼復制進去，並把Samy添加到那裡的任何英雄列表中，還附上一句話：「Samy‘s my hero 」。同樣，任何查看該用戶簡介的人也會被感染，這樣Samy的名聲和「人氣」迅速 擴大到100萬MySpace會員。同時造MySpace當機。 87

XSS攻擊案例2

Demo Cookie Stealing by Cross Site Scripting Tutorial Facebook XSS Vulnerability [02_04_2011] XSS In Facebook XSS in Skype for iOS Plurk Worm

Insecure Direct Object Reference

Insecure Direct Object Reference （不安全的物件參考） 攻擊者利用Web應用程式本身的檔案讀取功能任 意存取檔案或重要資料 例如： http://example/read.php?file=../../../../../../../c:\boo t.ini。 http://example/read.php?file=../../../../../../../c:\boot.ini read.php的作用式讀取網站底下的某個檔案，若沒有過濾，攻擊者可以直接讀取伺服器的根目錄

Insecure Direct Object Reference (Cont.) 避免將私密物件直接暴露給使用者 驗證所有物件是否為正確物件 使用 Index / Hash 等方法，而非直接讀取檔案

Demo OWASP Mantra - Insecure Direct Object References

Security Misconfiguration

Security Misconfiguration 系統的安全性取決於應用程式、伺服器、平台的 設定。因此所有設定值必須確保安全，避免預設 帳號、密碼、路徑等。甚至被 Google Hacking 直接取得攻擊弱點。

Security Misconfiguration (Cont.) 軟體、作業系統是否都有更新到最新版本？是否 都有上最新 Patch? 不需要的帳號、頁面、服務、連接埠是否都有關 閉？ 預設密碼是否都有更改？ 安全設定是否都完備？ 伺服器是否都有經過防火牆等設備保護？

Default Passwords http://www.phenoelit-us.org/dpl/dpl.html http://www.routerpasswords.com/ http://www.defaultpassword.com/

Default Passwords (Cont.) 123456 password abc123 admin 公司電話 我的生日、家人生日、心上人生日

Demo Payeasy帳號遭入侵 (民視新聞) DVWA Google HACK Security Cameras_

Insecure Cryptographic Storage

Insecure Cryptographic Storage （未加密的儲存設備） Web應用程式沒有對敏感性資料使用加密、使用 較弱的加密演算法或將金鑰儲存於容易被取得之 處。

Insecure Cryptographic Storage (Cont.) 使用現有公認安全的加密演算法 減少使用已有弱點的演算法，例如 MD5 / SHA-1， 甚至更簡單的加密法 安全的保存私鑰

Demo SQL Injection _ MD5 crack (4:25開始)

Insufficient Transport Layer Protection

Insufficient Transport Layer Protection 網頁應用程式未在傳輸機敏資訊時提供加密功能， 或者是使用過期、無效的憑證，使加密不可信賴。 例如：攻擊者竊聽無線網路，偷取使用者cookie； 網站憑證無效，使用者誤入釣魚網站

Insufficient Transport Layer Protection (Cont.) 盡可能的使用加密連線 Cookie 使用 Secure Flag 確認加密憑證是有效並符合domain的 後端連線也使用加密通道傳輸 http://www.owasp.org/index.php/Transport_Layer_Pr otection_Cheat_Sheet

Cookie Secure Flag PHP setcookie ("TestCookie", "", time() -  3600, “/", ".example.com", 1);  JSP cookie.setSecure(true); ASP.NET cookie.Secure = True; setcookie ("TestCookie", "", time() - 3600, “/", ".example.com", 1); 送出一個名叫TestCookie的cookies，存活時間3600秒等於1小時，有效使用在根目錄，網址是example.com，1表示一定要透過TLS/SSL送出到客戶端。 cookie.setSecure(true); cookie.Secure = True; true表示一定要透過TLS/SSL送出到客戶端。

Demo OWASP_Wireshark

Insecure Communication

Insecure Communication （未加密的網路連線） 網頁傳送敏感資料時並未使用 SSL 或其他加密方 式。 攻擊者可以進行網路監聽或者MITM 攻擊竊 取機敏資訊。 例如網路銀行、機敏資訊頁面、登入頁面等等。 Internet

Insecure Communication （未加密的網路連線） GET http://secret.com/admin/secret.htm <form action=“http://www.example.com/login.php” METHOD=“GET”> GET http://secret.com/admin/secret.htm <form action=“http://www.example.com/login.php” METHOD=“GET”> 以網址傳值GET方式，傳送資料。

Man-In-The-Middle Attack Attacker Server Victim

Insecure Communication (Cont.) 使用經過認證的 SSL 金鑰加密 使用含 SSL 認證檢查的瀏覽器，避免認證被竄改 或假造 網站架構必須檢查在重要資訊傳輸過程中是否皆 有加密

Demo Lab Demo Wireshark

Information Leakage and Improper Error Handling

Information Leakage and Improper Error Handling （程式碼錯誤訊息外漏） Web 應用程式的執行錯誤訊息包含敏感資料，包 括系統檔案路徑或資料庫欄位名稱的揭露。

Information Leakage and Improper Error Handling (Cont.) 確保開發過程中，有完善的例外處理機制。 將錯誤處理頁面及資訊限制給管理者。 將 HTTP 回傳錯誤碼隱藏。

Demo SQL Information Leakage-1 SQL Information Leakage-2 (成大)

Failure to Restrict URL Access

Failure to Restrict URL Access （疏於限制 URL 存取權限） 網頁因為沒有權限控制，使得攻擊者可透過網址 直接存取能夠擁有權限或進階資訊的頁面。 例如管理介面、修改資料頁面、個人機敏資訊頁 面洩漏等等。

"Welcome to phpMyAdmin" AND " Create new database" filetype:php

常見網頁目錄或檔案 /admin /backup /logs /phpmyadmin /phpinfo.php /manage

Demo Failure to Restrict URL Access 書局

Malicious File Execution

Malicious File Execution （惡意程式執行） Web應用程式引入來自外部的惡意檔案並執行檔 案內容。 例如： include $_REQUEST['filename’]; $lang = $_REQUEST[‘langfile’]; include $_REQUEST['filename’]; $lang = $_REQUEST[‘langfile’]; $_REQUEST 預設通吃 $_GET / $_POST ，表示伺服器會執行使用者透過GET或POST到伺服器的檔案。

Malicious File Execution (Cont.) WRONG: require_once($_POST[‘unsafe_filename’] . ‘inc.php’); RIGHT: require_once($safe[‘filename’] . ‘inc.php’); require_once($_POST[‘unsafe_filename’] . ‘inc.php’); 直接引入使用者POST到伺服器的檔案到inc.php。 require_once($safe[‘filename’] . ‘inc.php’); 先將檔案過濾過存在一個安全的變數中，引入安全的檔案到inc.php。

Demo Lab WebGoat (Upload file) WebGoat (Upload file) Cookie Stealing by Cross Site Scripting Tutorial (4:50開始)

Cross-Site Request Forgery

Cross-Site Request Forgery （跨站冒名請求） 已登入 Web 應用程式的合法使用者執行到惡意的 HTTP指令，但 Web 應用程式卻當成合法需求處 理，使得惡意指令被正常執行。 例如 Web2.0 時代的社交網站等等，都是 CSRF 攻擊的天堂。

1.攻擊者瀏覽csrf.htm 2.攻擊者在csrf.htm留下帶有惡意連結的圖片 3.受害者不經意瀏覽csrf.htm，立刻就執行惡意連結 4.惡意連結執行成功

Cross-Site Request Forgery Prevention 確保網站內沒有任何可供 XSS 攻擊的弱點 在 Input 欄位加上亂數產生的驗證編碼 在能使用高權限的頁面，重新驗證使用者 禁止使用 GET 參數傳遞防止快速散佈 使用 Captcha 等技術驗證是否為人為操作

OWASP Solution OWASP CSRFTester Project OWASP CSRFGuard Project http://www.owasp.org/index.php/CSRFTester OWASP CSRFGuard Project http://www.owasp.org/index.php/Category:OWASP_C SRFGuard_Project OWASP CSRF Prevention Cheat Sheet http://www.owasp.org/index.php/Cross- Site_Request_Forgery_(CSRF)_Prevention_Cheat_S heet

Demo Lab CSRF 網路書局 DVWA PHPBB3 - Cross Site Request Forgery Vulnerability Exploitation Plurk Worm

Unvalidated Redirects and Forwards

Unvalidated Redirects and Forwards 網頁應用程式經常將使用者 Forward 或 Redirect 至其他頁面或網站，沒有驗證的機制。攻擊者可 將受害者導向至釣魚網站或惡意網站，甚至存取 受限制的資源。

Unvalidated Redirects and Forwards (Cont.) http://example.cc/redir.jsp?url=evil.com http://example.cc/func.jsp?fwd=admin.jsp http://g.msn.com/9SE/1?http://xxx.com http://example.cc/redir.jsp?url=evil.com http://example.cc/func.jsp?fwd=admin.jsp http://g.msn.com/9SE/1?http://xxx.com 表示redir.jsp、func.jsp這些網頁的功能是接收網址參數(GET)，然後轉向到指定網址(evil.com 或admin.jsp )。

Unvalidated Redirects and Forwards (Cont.) 非必要時避免使用 Redirect 及 Forward 驗證導向位置及存取資源是合法的

Demo Lab Demo Broken WordPress

Thanks for Your Attention! Q&A