Web application หรือเว็บไซต์ ถูกยึดครองโดยไม่ได้รับอนุญาต หมายถึงข้อใด

Web Application Security
เว็บแอปพลิเคชั่นหมายถึง แอปพลิเคชั่นที่สามารถเข้าใช้งานผ่านเว็บบราวเซอร์ หรือ HTTP(s) agent (พอร์ต 80 หรือ 443) องค์ประกอบของเว็บแอปพลิเคชั่นนั้นประกอบด้วย
- Web Application เป็นซอฟต์แวร์หลักที่ให้ผลลัพธ์เป็นข้อมูลและการทำงานต่างๆ ทำงานอยู่ใน Application Server
- Web Server เป็นเซิร์ฟเวอร์ที่ให้บริการคือการตอบสนองต่อการร้องขอการทำงานต่างๆ ผ่านเว็บ
- Application Server เป็นเซิร์ฟเวอร์ที่ Web Application ทำงาน
- Database Server เป็นเซิร์ฟเวอร์ฐานข้อมูลที่เก็บข้อมูลต่างๆ ของ Web Application

ปัญหาที่อาจเกิดขึ้นในแต่ละส่วน

การโจมตีระบบ
ในการโจมตีระบบเว็บแอปพลิเคชั่นนั้นสามารถโจมตีได้หลายๆ อย่าง โดยมีสาเหตุจาก
- ความผิดพลาดของผู้ดูแลระบบที่ติดตั้งและตั้งค่าระบบต่างๆ ไม่ดีพอ
- ความผิดพลาดจากผู้เขียนซอฟต์แวร์ที่เกี่ยวข้องกับการทำงานเช่น MS IIS เป็นต้น
- ความผิดพลาดจากผู้เขียนเว็บแอปพลิเคชั่นและองค์ประกอบที่เกี่ยวข้องอื่นๆ ที่ไม่ได้ตระหนักถึงการทำงานให้เกิดความปลอดภัยในระบบ

ตัวอย่างเทคนิคต่างๆที่ใช้ในการโจมตีเว็บแอปพลิเคชั่น
- Hidden Field Manipulation
- Cookie Poisoning
- Backdoors and debug options
- Application buffer overflows
- Stealth commanding
- 3rd party misconfigurations
- Known vulnerabilities
- Parameter tempering
- Cross site scripting
- Forceful browsing
- Hacking over SSL
- Sourcecode Disclosure
- Web Server Architecture Attack
- SQL Injection
- Java Script Injection

การสร้างความปลอดภัยในระบบ
กระบวนการในการแก้ปัญหา
1. System Scanner and Security Infrastructure Software
- การตรวจสอบความผิดพลาดจากการตัง้ ค่าต่างๆ ในระบบ
- เครื่องมือที่ช่วยตรวจสอบเรียกว่า System Scanner จะตรวจสอบการตัง้ ค่าต่าง ๆ ไม่ว่า
จะเป็น permission ต่างๆ, การตัง้ ค่าความปลอดภัยในระบบ และ web server

2. Secure Coding
- ปัญหาในการเขียนโค้ดในเว็บแอปพลิเคชั่น ซึ่งอยู่ที่โปรแกรมเมอร์ผู้พัฒนา ไม่คำนึงถึงการป้ องกัน
การทำงานที่ไม่ได้อยู่ในการควบคุมของโปรแกรม เช่น การควบคุมพารามิเตอร์บางอย่าง และการ
ตรวจสอบข้อมูลที่รับเข้ามา

สิ่งที่ควรคำนึงถึงเพิ่มเติมในการเขียนโค้ด
- การทำ input & output validation
- การใช้ SSL
- การใช้ HTML forms
- การใช้ Cookies
- การใช้ HTTP REFERER Header
- การใช้ POST & GET method
- มีกระบวนการในการทำ logout (logout machanism)
- Error Handling

การทำ input & output validation
     ในการทำงานโดยปกติของเว็บแอปพลิเคชั่น จะมีการรอรับข้อมูลบางอย่างจากยูสเซอร์เพื่อใช้ในการทำงานแล้ว จึงส่งผลลัพธ์ไปให้ยูสเซอร์ ซึ่งอินพุทจากยูสเซอร์ก็เป็นสาเหตุหลัก ที่จะทำให้ระบบเกิดความไม่ปลอดภัยได้ โดยผู้เขียนเว็บแอปพลิเคชั่นพึงระลึกไว้เสมอว่าไม่ควรเชื่อถือข้อมูลใดๆ ที่ส่งมาจากฝั่งไคลเอนต์ (NEVER
TRUST CLIENT SIDE DATA)
     ทำ Sanity Checking โดยการตรวจสอบอินพุททุกอย่างที่เข้ามาในระบบ เพื่อตรวจดูว่าข้อมูลที่เราต้องการมี
อะไรบ้าง ยกตัวอย่างเช่นถ้าอินพุทที่ต้องการใช้งานนั้นเป็นเพียงค่า YES หรือ NO เท่านั้น ก็ทำการ drop ข้อมูล
อื่นๆ ที่รับเข้ามาทิ้งไป หรือถ้าข้อมูลที่ต้องการรับเข้ามาเป็นเพียงตัวเลขที่อยู่ในช่วงตัวเลขช่วงหนึ่งก็ต้องมีการ
ตรวจสอบค่าตัวเลขที่รับเข้ามาก่อนที่จะนำเอาไปใช้งาน
     ควรมีการตรวจสอบตัวอักขระพิเศษต่างๆ ด้วย เพราะตัวอักขระพิเศษต่างๆ มักจะเป็นต้นกำเนิดของปัญหาการ
ใช้ฟังก์ชั่น หรือ system call ที่ผิดปกติ การทำ directory traversal โดยเฉพาะอย่างยิ่ง NULL character ซึ่งปกติ
แล้วจะไม่มีการใช้งาน
     ถ้าเว็บแอปพลิเคชั่นไม่จำเป็นต้องใช้งานตัวอักษร HTML ต่างๆ ก็ควรทำการกรองตัวอักษร HTML ก่อน และ
เปลี่ยนรูปแบบอักขระให้อยู่ในรูปอื่นๆ ที่ปลอดภัยกว่า ก่อนที่จะนำเข้ามาเป็นอินพุทของเว็บแอปพลิเคชั่น เช่น

> เปลี่ยนเป็น >
< เปลี่ยนเป็น <
“ เปลี่ยนเป็น "
& เปลี่ยนเป็น &

Tag HTML ที่อาจเป็นปัญหา ได้แก่
- <APPLET> , <BASE> , <BODY> , <EMBED> , <FRAME>, <FRAMESET> , <HTML> , <IFRAME> , <IMG> , <LAYER> , <META> , <OBJECT> , <P> , <SCRIPT> ,<STYLE>

- HTML tag ที่มี attributes ต่อไปนี้ <STYLE> , <SRC> , <HREF> , < TYPE>

การใช้ SSL
โพรโตคอล HTTP ที่ใช้งานกันอยู่ในปัจจุบันมีจุดบกพร่องในด้านการรักษาความปลอดภัย 2 ประการ
หลักๆ คือข้อมูล HTTP เป็นข้อมูล Plaintext ซึ่งสามารถดักจับได้โดยโปรแกรม Sniffer ต่างๆ และโพรโตคอล
HTTP ยังไม่สามารถตรวจสอบความถูกต้องของข้อมูลที่รับส่งนั้นๆ ในการรักษาความปลอดภัยในโพรโตคอล
HTTP SSL (Secure Socket Layer) เป็นระบบการรักษาความปลอดภัยในการสื่อสารระหว่าง Web Client กับ
Web Server สำหรับ SSL นั้นเป็นการทำงานในชั้น transport ที่ช่วยในการสร้างความปลอดภัย 3 ข้อคือ
1. การเข้ารหัสข้อมูล
2. การทำ Client & Server Authentication
3. การทำ Data Integrity

การใช้ HTML forms
การใช้ hidden form element นั้นช่วยให้การทำงานหลายๆ อย่างทำได้สะดวกมากขึ้น โดยระบบจะมอง
ข้อมูลที่อยู่ใน hidden เป็นเหมือนกับข้อมูลที่รับมาจากยูสเซอร์ แต่การใช้งาน hidden element ไม่ควรใช้กับ
ข้อมูลที่มีความสำคัญมากๆ เช่น ราคาสินค้า รหัสที่แทนผู้ใช้งาน ค่าพารามิเตอร์ต่างๆ ที่มีผลต่อการทำงานของ
เว็บแอปพลิเคชั่น

การใช้ Cookies
Cookies เป็นเนื้อที่ในการเก็บข้อมูลในการทำงานบางส่วนไว้ที่ไคลเอนต์โดย Cookie มีอยู่ 2 ประเภทคือ
persistent : เป็น Cookie ที่ไม่มีการลบข้อมูลออกแม้ว่าจะปิดแอปพลิเคชั่นไปแล้วก็ตาม
non-persistent : เป็น Cookie ที่จะลบข้อมูลออกจากไคลเอนต์เมื่อหมดเวลา หรือเมื่อปิดแอปพลิเคชั่นไปแล้ว
Cookies นั้นมีประโยชน์สำหรับเว็บแอปพลิเคชั่นในการทำงาน 3 ลักษณะคือ
- User Authentication
- State Management
- Saving user preference

หลักการในการใช้งาน Cookies เพื่อความปลอดภัย
- ไม่ควรเก็บข้อมูลใน Cookies เป็น Plaintext หรือเข้ารหัสข้อมูลแบบหลวมๆ
- ควรคำนึงไว้เสมอๆ ว่าข้อมูลใน Cookies นั้นไม่ปลอดภัย
- ถ้าใช้งาน Cookies ควรระมัดระวังสองกรณีคือ ไม่ควรมีคนอื่นๆ มาใช้งาน Cookies ได้ และไม่ควรมี
ใครรู้ข้อมูลใน Cookies ไม่ว่ากรณีใดๆ
- ควรมีการเซต restrictive path ใน Cookies
- ในการตรวจสอบ Authentication นั้นไม่ควร valid ถ้าทำงานเกินช่วงเวลาที่ตั้งไว้
- ข้อมูลที่เก็บไว้ใน Cookies ควรเป็นข้อมูลที่ใช้ชั่วคราวเท่านั้น
- ในการสร้าง Token ID ควรใช้อัลกอริทึมที่มีประสิทธิภาพ ไม่สามารถคาดเดาได้
- ใช้ Cookies Timeout สำหรับลบ Cookies ที่ไม่มีการใช้งานออกจากระบบ
- การทำ Authentication ควรใช้ข้อมูลของไอพีแอดเดรสมาประกอบด้วยโดย สำหรับ Business Intranet
ควรใช้ไอพีแอดเดรสทั้ง 32 บิต สำหรับการใช้งานเว็บทั่วๆ ไป ควรใช้ข้อมูล 16 บิต มาประกอบการทำ
authentication ด้วย
- ในการทำ Authentication ควรใช้ข้อมูลเกี่ยวกับไคลเอนต์มาประกอบด้วยเช่นการใช้ header ที่เป็น
ค่าคงที่และแตกต่างกันในแต่ละไคลเอนต์เช่น User-Agent , Accept-Language , Etc.

การใช้ HTTP REFERER Header
การป้องกัน script attack อีกทางหนึ่งที่สามารถป้องกัน script attack ได้บ้างคือการใช้ HTTP
REFERER header แต่ก็ไม่สามารถป้องกันได้ทั้งหมด เนื่องจาก HTTP REFERER นั้นก็ยังเป็นข้อมูลในฝั่ง
ไคลเอนต์ที่สามารถปลอมแปลงได้เช่นกัน

การใช้ POST & GET method
ไม่ควรใช้ method GET ในการส่งข้อมูลที่มีความสำคัญ เนื่องจากข้อมูลจะไปปรากฏในอุปกรณ์หลายๆ
อย่างในเส้นทางที่แพ็กเก็ตผ่านไปเช่น Proxy Server, Firewall , Web Servers log เป็นต้น ในกรณีที่เว็บ
แอปพลิเคชั่นมีการใช้งาน POST เท่านั้น ก็ควรตั้งค่าให้เว็บเซิร์ฟเวอร์ตอบสนองเฉพาะ POST เท่านั้น และไม่
ตอบสนองต่อ method อื่นๆ เลย การทำเช่นนี้สามารถป้องกันการโจมตีโดยใช้ client side script ได้ ถึงแม้ว่า
POST method จะใช้งานได้ดีและปลอดภัยมากกว่า GET แต่ก็ยังไม่สามารถป้องกันการดักจับข้อมูลได้

logout (logout machanism)
การเพิ่มกระบวนการในการ logout ในการทำงานต่างๆ ในเว็บแอปพลิเคชั่นนั้น มีประโยชน์ในการ
ลบ Cookies หรือทำให้ Cookies ที่ฝั่งไคลเอนต์ไม่สามารถทำงานได้ จัดการกับ session ทางฝั่งเซิร์ฟเวอร์เพื่อ
ป้องกันการขโมย session ในกรณีที่ Cookies ที่ไคลเอนต์ยังไม่หมดอายุ

Error Handling Mechanism
การทำ Error Handling ที่มีการแจ้ง Error Description นั้นเป็นประโยชน์ในการดีบักปัญหาต่างๆ แต่ไม่
ควรส่ง Error Description ต่างๆ ไปให้ยูสเซอร์ เนื่องจากจะทำให้ผู้บุกรุกสามารถรู้รายละเอียดในระบบได้ ใน
กรณีที่จำเป็นต้องส่ง Error Desciption ต่างๆ ไปให้ยูสเซอร์ ก็ควรมีการกรองข้อมูลก่อนที่จะส่งด้วย ในการแจ้ง
Error Desciption ก็ไม่ควรแจ้งลงรายละเอียดมากเกินไปจนทำให้ผู้บุกรุกสามารถคาดเดาได้ว่าระบบมีข้อมูล และ
การทำงานอย่างไร

Injection Flaws

หมายถึง แฮกเกอร์สามารถที่จะแทรก Malicious Code หรือ คำสั่งที่แฮกเกอร์ใช้ในการเจาะระบบส่งผ่าน Web Application ไปยังระบบภายนอกที่เราเชื่อมต่ออยู่ เช่น ระบบฐานข้อมูล SQL โดยวิธี SQL Injection หรือ เรียก External Program ผ่าน shell command ของระบบปฎิบัติการ เป็นต้น

ส่วนใหญ่แล้วแฮกเกอร์จะใช้วิธีนี้ในช่วงการทำ Authentication หรือการ Login เข้าระบบผ่านทาง Web Application เช่น Web Site บางแห่งชอบใช้ "/admin" ในการเข้าสู่หน้า Admin ของ ระบบ ซึ่งเป็นช่องโหว่ให้แฮกเกอร์สามารถเดาได้เลยว่า เราใช้ http://www.mycompany.com/admin ในการเข้าไปจัดการบริหาร Web Site ดังนั้นเราจึงควรเปลี่ยนเป็นคำอื่นที่ไม่ใช่ "/admin" ก็จะช่วยได้มาก

วิธีการทำ SQL injection ก็คือ แฮกเกอร์จะใส่ชื่อ username อะไรก็ได้แต่ password สำหรับการทำ SQL injection จะใส่เป็น Logic Statement ยกตัวอย่างเช่น ' or '1' = '1 หรือ " or "1"= "1

ถ้า Web Application ของเราไม่มีการเขียน Input Validation ดัก password แปลกๆ แบบนี้ แฮกเกอร์ก็สามารถที่จะ bypass ระบบ Authentication ของเราและ Login เข้าสู่ระบบเราโดยไม่ต้องรู้ username และ password ของเรามาก่อนเลย

วิธีการเจาะระบบด้วย SQL injection ยังมีอีกหลายแบบจากที่ยกตัวอย่างมา ซึ่งแฮกเกอร์รุ่นใหม่สามารถเรียนรู้ได้ทางอินเทอร์เน็ตและวิธีการทำก็ไม่ยาก อย่างที่ยกตัวอย่างมาแล้ว

วิธีการป้องกัน

นักพัฒนาระบบ ((Web Application Developer ควรจะระมัดระวัง input string ที่มาจากทางฝั่ง Client (Web Browser) และไม่ควรใช้วิธีติดต่อกับระบบภายนอกโดยไม่จำเป็น

ควรมีการ "กรอง" ข้อมูลขาเข้าที่มาจาก Web Browser ผ่านมาทางผู้ใช้ Client อย่างละเอียด และ ทำการ "กรอง" ข้อมูลที่มีลักษณะที่เป็น SQL injection statement ออกไปเสียก่อนที่จะส่งให้กับระบบฐานข้อมูล SQL ต่อไป

การใช้ Stored Procedure หรือ Trigger ก็เป็นทางออกหนึ่งในการเขียนโปรแกรมสั่งงานไปยังระบบฐานข้อมูล SQLซึ่งมีความปลอดภัยมากกว่าการใช้ "Dynamic SQL Statement " กับฐานข้อมูล SQL ตรงๆ

Improper Error Handling
หมายถึง มีการจัดการกับ Error message ไม่ดีพอ เวลาที่มีผู้ใช้ Web Application หรืออาจจะเป็นแฮกเกอร์ลองพิมพ์ Bad HTTP Request เข้ามาแต่ Web Server หรือ Web Application ของเราไม่มีข้อมูล จึงแสดง Error messageออกมาทางหน้า Browser ซึ่งข้อมูลที่แสดงออกมาทำให้แฮกเกอร์สามารถใช้เป็นประโยชน์ ในการนำไปเดาเพื่อหาข้อมูลเพิ่มเติมจากระบบ Web Application ของเราได้ เนื่องจากเมื่อการทำงานของ Web application หลุดไปจากปกติ ระบบมักจะแสดงค่า Error Message ออกมาแสดงถึงชื่อ user ที่ใช้ในการเข้าถึงฐานข้อมูล, แสดง File System Path หรือ Sub Directory Name ที่ชี้ไปยังไฟล์ฐานข้อมูล ตลอดจนทำให้แฮกเกอร์รู้ว่าเราใช้ระบบอะไรเป็นฐานข้อมูลเช่น ใช้ MySQLเป็นต้น

วิธีการแก้ปัญหา

ควรมีการกำหนดนโยบายการจัดการกับ Error message ให้กับระบบ โดยทำหน้า Error message ที่เตรียมไว้รับเวลามี Bad HTTP Request แปลกๆ เข้ามายัง Web Application ของเราโดยหน้า Error message ที่ดีไม่ควรจะบอกให้ผู้ใช้รู้ถึงข้อมูลระบบบางอย่างที่ผู้ใช้ทั่วไปไม่ควรรู้และถ้าผู้ใช้คนนั้นเป็นแฮกเกอร์ซึ่งย่อมมีความรู้มากกว่าผู้ใช้ธรรมดา การเห็นข้อมูล Error message ก็อาจนำไปใช้เป็นประโยชน์สำหรับแฮกเกอร์ได้

Insecure Storage

หมายถึง การเก็บรหัสผ่าน (password), เบอร์บัตรเครดิตลูกค้า หรือ ข้อมูลลับของลูกค้า ไว้อย่างไม่มีความปลอดภัยเพียงพอ ส่วนใหญ่จะเก็บแบบมีการเข้ารหัส (Encryption) ไว้ในฐานข้อมูลหรือ เก็บลงในไฟล์ที่อยู่ใน Web serverและคิดว่าเมื่อเข้ารหัสแล้วแฮกเกอร์คงไม่สามารถอ่านออก แต่ สิ่งที่เราคิดนับว่าเป็นการประเมินแฮกเกอร์ต่ำเกินไป เนื่องจากอาจเกิดข้อผิดพลาดในการเข้ารหัส เช่น การเข้ารหัสนั้นใช้ Algorithm ที่อ่อนเกินไป ทำให้แฮกเกอร์แกะได้ง่ายๆ หรือมีการเก็บกุญแจ (key) หรือ รหัสลับ (Secret password) ไว้เป็นไฟล์แบบง่ายๆ ที่แฮกเกอร์ สามารถเข้าถึงได้ หรือ สามารถถอดรหัสได้โดยใช้เวลาไม่มากนัก

วิธีการแก้ไข

ควรมีการเข้ารหัสไฟล์ โดยใช้ Encryption Algorithm ที่ค่อนข้างซับซ้อนพอสมควร หรือแทนที่จะเก็บรหัสผ่านที่เข้ารหัสไว้ ให้หันมาเก็บค่า Message Digest หรือ ค่า "HASH" ของรหัสผ่านทาง โดยใช้ Algorithm SHA-1 เป็นต้น

การเก็บกุญแจ (key), ใบรับรอง ดิจิตัล (Digital Certificate) หรือ ลายมือชื่อดิจิตัล (Digital Signature) ควรเก็บไว้อย่างปลอดภัย เช่น เก็บไว้ใน Token หรือ Smart Card ก็จะปลอดภัยกว่าการเก็บไว้เป็นไฟล์ในฮาร์ดดิสค์ เป็นต้น (ถ้าเก็บเป็นไฟล์ก็ควรทำการเข้ารหัสไว้ทุกครั้ง)

Denial of Service

หมายถึงระบบ Web Application หรือ Web Server ของเรา อาจหยุดทำงานได้เมื่อเจอกับ Bad HTTP Requestแปลกๆ หรือ มีการเรียกเข้ามาอย่างต่อเนื่องจำนวนมาก ทำให้เกิดการจราจรหนาแน่นบน Web Server ของเรา โดยปกติWeb Server จะจัดการกับ Concurrent session ได้จำนวนหนึ่ง ถ้ามี HTTP Request เข้ามาเกินค่าที่ Web Server จะสามารถรับได้ ก็จะเกิด Error ขึ้น ทำให้ผู้ใช้ไม่สามารถเข้า Web Site เราได้ นอกจากนี้ อาจจะทำให้เครื่องเกิด CPU Overload หรือ Out of Memory ก็เป็นรูปแบบหนึ่งของ Denial of Service เช่นกัน กล่าวโดยรวมก็คือ ทำให้ระบบของเรามีปัญหาเรื่อง "Availability"

วิธีการแก้ไข

การป้องกัน DoS หรือ DDoS Attack นั้นไม่ง่าย และ ส่วนใหญ่ ไม่สามารถป้องกันได้ 100% การติดตั้ง Hardware IPS (Intrusion Prevention System) เป็นอีกทางเลือกหนึ่ง แต่ก็มีค่าใช้จ่ายค่อนข้างสูง หากต้องการประหยัดงบประมาณก็ควรต้อง ทำการ "Hardening" ระบบให้เรียบร้อย เช่น Network OS ที่ใช้อยู่ก็ควรจะลง Patch อย่างสม่ำเสมอ, Web Server ก็เช่นเดียวกัน เพราะมีช่องโหว่ เกิดขึ้นเป็นประจำ ตลอดจนปรับแต่งค่า Parameter บางค่าของ Network OS เพื่อให้รองรับกับการโจมตีแบบ DoS /DDoS Attack

Insecure Configuration Management

หมายถึง เป็นปัญหาที่เกิดขึ้นจากผู้ดูแลระบบ หรือ ผู้ติดตั้ง Web Server มักจะติดตั้งในลักษณะ "Default Configuration" ซึ่งยังคงมีช่องโหว่มากมาย หรือบางครั้งก็ไม่ได้ทำการ Update Patch ระบบให้ครบถ้วนจนถึง Patchล่าสุด

ปัญหาที่เจอบ่อยๆ ก็คือมีการกำหนดสิทธิในการเข้าถึงไฟล์ต่างๆ ใน Web Server ไม่ดีพอทำให้มีไฟล์หลุดออกมาให้ผู้ใช้เข้าถึงได้ เช่น แสดงออกมาในลักษณะ "Directory Browsing" ตลอดจนค่า default ต่างๆ ไม่ว่าจะเป็น Default Username และ Default Password ก็มักจะถูกทิ้งไว้โดยไม่ได้เปลี่ยนอยู่เป็นประจำ

วิธีการแก้ปัญหา

ให้ทำการแก้ไขค่า "Default" ต่างๆ ทันทีที่ติดตั้งระบบเสร็จ และทำการ Patch ระบบให้จถึง Patch ล่าสุด และ ตามPatch อย่างสม่ำเสมอ เรียกว่า ทำการ "Hardening" ระบบนั่นเอง Services ใดที่ไม่ได้ใช้ก็ไม่ต้องเปิดบริการ เราควรตรวจสอบสิทธิ File and Subdirectory Permission ในระบบว่าตั้งไว้ถูกต้อง และ ปลอดภัยหรือไม่ ตลอดจนเปิดระบบ Web Server log file เพื่อที่จะได้สามารถตรวจสอบ (Audit) HTTP Request ที่ส่งมายัง Web Server ได้ โดยดูจาก Web Server log file ที่เราได้เปิดไว้ และ เราควรหมั่นติดตามข่าวสารเรื่องช่องโหว่ (Vulnerability) ใหม่ๆ อย่างสม่ำเสมอ และ มีการตรวจวิเคราะห์ Web Server log file, Network log file, Firewal log file และ IDS/IPS log file เป็นระยะๆ

จะเห็นได้ว่าแฮกเกอร์ในปัจจุบันสามารถเจาะระบบเราโดยผ่านทะลุ Firewall ได้อย่างง่ายดาย เพราะ เรามีความจำเป็นต้องเปิดให้บริการ Web Server ในทุกองค์กร ดังนั้นการตรวจสอบเรื่องของ Web Application Source Code และWeb Server Configuration จึงเป็นทางออกสำหรับการแก้ไขปัญหาทางด้านความปลอดภัยของระบบให้รอดพันจากเหล่าไวรัสและแฮกเกอร์ซึ่งนับวันจะเพิ่มจำนวนและเพิ่มความสามารถขึ้นเป็นทวีคูณ.