ความคิดเห็นที่ 1 ผมไม่เกี่ยวกับ scb นะครับ แต่ทำงานด้านนี้มาบ้าง ขอทราบรายละเอียดเพิ่มเติมหน่อยได้ไม๊ครับ 1.เครื่องที่คุณใช้เปิด เป็นเครื่องเดียวกับเครื่องที่เพื่อนคุณใช้เปิดใช่หรือไม่ 2.เพื่อนคุณ เพิ่งเข้าเว็บนี้มาไม่นานก่อนที่คุณจะมาเปิด link นี้ใช่หรือไม่ สาเหตุที่ต้องถาม ก็เพราะว่า 1. scb ไม่น่าจะส่ง session id ไปกับ link (แต่ถ้าส่งก็น่ากัวจริง) 2. จากข้อมูลที่ให้มา ผมเดาว่าเพื่อนคุณเพิ่งใช้งานมาไม่นาน (ไม่น่าเกิน 30 นาที) ก่อนที่คุณจะมาเปิดใช่รึเปล่าครับ กรณีนี้อาจจะเป็นเพราะว่า session ยังไม่ time out ยังไงช่วยอธิบายเพิ่มอีกสักนิดนะครับ เผื่อจะช่วยแนะนำอะไรได้ จากคุณ : test (^pop^) เขียนเมื่อ : 3 ธ.ค. 54 01:11:43

ความคิดเห็นที่ 2 ผมไม่เชื่อว่าทำได้ เครื่องเดียวกันลองดูเมื่อกี้ยีงไม่ได้เลย ประกอบกับก็มี timeout อยู่อีกด้วย จากคุณ : delight เขียนเมื่อ : 3 ธ.ค. 54 01:12:43

ความคิดเห็นที่ 3 1) คนละเครื่องครับ เน็ตคนละค่าย คุยกันผ่าน google talk (pidgin) แล้วเพื่อนก็เผลอก๊อปติด link มาด้วยแค่นั้นเอง 2) ก็คุยกันแล้วก็ก๊อปกันสดๆ เนี่ยแหละครับ ถ้าปล่อยทิ้งไว้ซักพักก็ไม่ได้แล้ว แต่ถึงยังไงก็ไม่ควรจะใช้ได้อยู่ดี ไม่ว่ากรณีไหน link ที่ได้จะหน้าตาประมาณนี้ครับ https://www.scbeasy.com/easyfund/List_statement.asp?Cli=############&AC=##########&IDCARD=35281635180*****283518*****81F35282*****2635282635182835181835182C35*****5181C&userid=############&scode=*****7Oaz*****gDrCv0V0D6*****aVj3LkWh93ce*****&fund_code=SCBDV%20&flag_bal=Y&Ubal=1 ขอ censor บางส่วนทิ้งนะครับ อันนี้ก๊อปมาเอง จากตรงเนี้ย จากคุณ : worldicez เขียนเมื่อ : 3 ธ.ค. 54 01:27:48

ความคิดเห็นที่ 4 SCB ส่ง Session ID ไปกับ LINK จริงๆ ครับ ในส่วนของ Easy Fund ซึ่งคนละอันกับ SCB Easy ปกตินะครับ https://www.scbeasy.com/easyfund/Unit_Balance.asp?Cli=???? &AC=5?????????&IDCARD=?????????&userid=??????????&scode=??????????????&USER_LIST=?????????&Encryp=X3?????? ผมเซ็นเซอร์ไว้นะครับ แต่ดู Parameter สิครับ ครบทุกอย่างเลย จากคุณ : zephythor (ZephyThor) เขียนเมื่อ : 3 ธ.ค. 54 01:28:07

ความคิดเห็นที่ 5 ซึ่งที่ทดสอบแล้ว... link ทุก link ในส่วนของ easyfund สามารถ copy แจกให้คนอื่นดูได้หมดเลยครับ จากคุณ : worldicez เขียนเมื่อ : 3 ธ.ค. 54 01:28:45

ความคิดเห็นที่ 6 อ้อ ในหน้า Easy Fund เป็นทุกๆ Link ในระบบเลยครับ เหมือนโปรแกรมเมอร์ จะใช้การส่ง session ผ่าน GET ธรรมดา -___-" ซึ่งไม่ควรจะเป็นแบบนี้เลยนะครับ จากคุณ : ZephyThor เขียนเมื่อ : 3 ธ.ค. 54 01:29:09

ความคิดเห็นที่ 7 เบื้องต้นผมลองเทสดู ไม่เห็นว่าทำได้เช่นกันครับ ( เข้าหน้าEasy Fund ) เลยอยากให้พี่ worldicez  ช่วยแชร์ว่าทำอย่างไรถึงได้หรือครับ เพราะหากว่าหลุดจริงๆ พี่ๆเขาจะได้เร่งแก้ไขกันครับ ช่วยๆกันตรวจสอบครับ เพื่อความมั่นใจของพวกเรา ^^ ปล.พี่ใช้ Browser อะไรครับ ,, ผมใช้ Chrome มันคลิ๊กขวาไม่ได้ + ก๊อปปี้ url ด้านบนไปเปิดที่อื่นก็ไม่ได้ แต่หากเอาเมาส์ชี้ที่ Link ก็จะเห็นว่าส่ง Script อะไรไปให้ Server บ้าง(ถ้าหากเรียกผิดขออภัย) แต่ก็คลิ๊กขวาก๊ิอป link ดังกล่าวมาไม่ได้อยู่ดีครับ ปล2.เพิ่มเติมว่าผมไม่มีหน่วยกองทุนคงเหลือ เลยเข้าไปลองกดไม่ได้ เข้าได้แค่ column "ไม่มีหน่วยลงทุนคงเหลือ" แล้วไปกดที่ SCBSET ที่เคยซื้อเพื่อจะเข้าไปดู History แล้วมันขึ้น Link URL ด้านบนแค่นี้อะครับ https://www.scbeasy.com/v1.4/site/Library/frame_efn.asp (แต่ถ้าเอาเม้าส์ชี้ก็เห็น url ลอยๆเหมือนด้านล่างเหมือนกัน ^^) แก้ไขเมื่อ 03 ธ.ค. 54 01:42:00 จากคุณ : มิ่งกลิ้ง เขียนเมื่อ : 3 ธ.ค. 54 01:30:05

ความคิดเห็นที่ 8 เป็น web cache ที่ค้างอยูในเครื่องหรือเปล่าครับ จากคุณ : จันทร์สะท้อนเงา เขียนเมื่อ : 3 ธ.ค. 54 01:34:11

ความคิดเห็นที่ 9 ถ้า Firefox คลิกขวาสักสองที มันก็จะถามแล้วครับ ว่าให้ Block Popup นี้ไปไหม ถ้าตอบ Yes มันก็จะคลิกได้แล้วครับ ไม่ก็ลองใช้ Plugin Allow right click เพื่อทดสอบได้ครับ จากคุณ : ZephyThor เขียนเมื่อ : 3 ธ.ค. 54 01:34:26

ความคิดเห็นที่ 10 ถ้าไม่ลำบากเกินไป ... ทำแถบสี แล้ว copy ไปแปะใน word ครับ มันจะได้เป็น link ออกมาเลย หรือสำหรับ firefox ให้ตั้ง option ตามรูปข้างล่างนี้เลยครับ แค่นี้ก็คลิกขวา copy link ได้อย่างสบายใจ... #8 cache แบบมีชื่อเพื่อนติดมาด้วย ไม่ใช่มั้งครับ แถมกด back กด link ไปหน้าอื่นๆ ได้สบายเลยด้วย แถมขึ้นรายการยอดเงินของบัญชีเพื่อนมาเรียบร้อย ทั้งๆ ที่เครื่องที่เข้าน่ะเครื่องคอมส่วนตัวผมเอง ที่ไม่เคยมีคนอื่นมาเล่น จากคุณ : worldicez เขียนเมื่อ : 3 ธ.ค. 54 01:46:39

ความคิดเห็นที่ 11 อ้าว ลืมแนบรูป T_T จากคุณ : worldicez เขียนเมื่อ : 3 ธ.ค. 54 01:47:38

ความคิดเห็นที่ 12 ขอติดตามกระทู้ด้วยคน เป็นความรู้ด้วย ^^ จากคุณ : พรุ่งนี้มาดูต่อ :P (มิ่งกลิ้ง) เขียนเมื่อ : 3 ธ.ค. 54 01:51:07

ความคิดเห็นที่ 13 ปล.ทำได้ละ ง่ายกว่าที่คิด ใช้กด Link แล้วลากไปเปิด new tab เอา ได้ข้อมูล url มาหมดเลย (เทสบน Chrome & IE) เอาไปเปิดที่อื่นได้จริงๆด้วย เข้าใจว่าถ้ายังไม่ session timeout ก็เล่นได้หมดเลย ... ทาง SCB ใช้ Method GET แบบที่พี่ ZephyThor แจ้งป่ะครับ ปล.ช่วยตรวจสอบนะครับ เนื่องจากใช้ scbeasy เหมือนกัน ก็ไม่อยากให้มีช่องโหว่ครับ หรือถ้าผมเข้าใจอะไรผิด ก็ขออภัยด้วยครับ เด๋วมาติดตามใหม่ ^^ จากคุณ : เป็นกำลังใจให้นะครับ (มิ่งกลิ้ง) เขียนเมื่อ : 3 ธ.ค. 54 02:29:56

ความคิดเห็นที่ 14 ดูจาก #4 เป็นการส่ง Parameter ครบทุกตัว ผ่าน URL ซึ่งคงใช้งานได้ทุกอย่างจนกว่า User ตัวจริงจะ Logout หรือ Session TimeOut นั่นแสดงว่า ระบบใช้ Session เก็บข้อมูลเพียงแค่ ID ของผู้ใช้งานหลังจากที่มีการ Login  และมีการตรวจสอบสิทธิ์การใช้งานในแต่ละเพจที่ Server เท่านั้น ไม่ได้ตรวจสอบสิทธิ์การใช้งานของเครื่อง Client ที่เก็บเป็น Session เลย  (ผมวิเคราะห์แบบนี้ถูกรึเปล่านะ ) โอกาสที่จะแฮ๊คและสร้างความปั่นป่วนได้ก็มีเหมือนกันแต่ก็น้อยมาก นอกจากว่าจะเป็นการพุ่งเป้าโจมตีหรือตั้งใจแอบดูข้อมูลใครคนใดคนหนึ่งโดยเฉพาะ ซึ่งถ้าไม่ใช่คนฝีมือดีๆและมั่นใจในตัวเองสูง คงไม่กล้าไปป่วนชาวบ้านหรอก อย่างมากก็แค่แอบดูข้อมูลเล่นๆ คำแนะนำ : แก้โค้ดปัญหาเฉพาะหน้าไปก่อน โดยเปลี่ยนวิธีส่งข้อมูลเป็นแบบ Session และ Post ให้มาแทนมากขึ้น พร้อมกับเขียนโปรเจคใหม่โดยใช้ java หรือ asp.net เสียดายผมไม่ได้เล่นกองทุนของ SCB ไม่งั้นจะตรวจสอบดูเรื่องอื่นๆที่อาจจะเป็น Defect ให้ด้วย จากคุณ : Rapter เขียนเมื่อ : 3 ธ.ค. 54 03:37:34

ความคิดเห็นที่ 15 จากการทดลองทำโดย Login เข้า SCB EASY แล้วไป EASY FUND แล้วไป COPY LINK มา 1 Link ซึ่งทำโดยการ SELECT รอบๆ HYPERLINK แล้วกด CTRL + C จากนั้นไปวางใน WORD แล้วเอา LINK ออกมา จากนั้นเอา LINK นั้นไปใส่ในเครื่องที่อยู่ที่อื่น (Server ที่ทำงาน โดยการ Remote ไป) พบว่าสามารถเข้าไปได้จริงๆ และสั่งทำการซื้อขายหุ้นได้ด้วย แต่...พอผมกด Log Out จากเครื่องหลักที่ผมเล่นอยู่ที่บ้าน ทางฝั่ง Office ผมก็กดไปไหนต่อไม่ได้แล้วเช่นกัน หรือเปิดค้างไว้นานๆ 10 นาที ทางฝั่งเครืองที่อยู่ที่ทำงานก็กดเข้าไปดูหน้าอื่นๆไม่ได้แล้วครับ (ต้องห้ามกด Link ทั้งสองฝั่ง) ส่วนตัวถามว่าปลอดภัยไหม ก็ขอตอบว่าปลอกภัยระดับหนึ่ง - เพราะใช้ https ทำให้ url ที่ส่งไปโดยเข้ารหัสยากแก่การดักฟัง - และก็ไม่ใช้ COOKIE ในการ ยืนยัน ซึ่งก็เป็นข้อดี เพื่อป้องกัน HACKER มานั่งถอดรหัส COOKIE แล้วทำ COOKIE เสมือนขึ้นมา ส่วนความเสี่ยงที่คิดว่าหลายคนกลัวว่า จะมีคนมา HACK ข้อมูลเราไปนั้น ผมขอวิเคราะห์ว่าโอกาสเกิดดังนี้ 1. เปิด SCBEASY แล้วมีคนมา COPY LINK จากเครื่องเราไป แล้วไปกดที่เครื่องเขาต่อ --> แต่ป้องกันได้โดยการกด LOGOUT ทุกครั้งที่เลิกใช้ 2. โดยพวก VIRUS ดักเก็บ LINK ที่เรากด แล้วส่งไปให้ผู้ไม่หวังดี ซึ่งถ้า SCBEASY จะช่วยปรับปรุงนิดนึง โดยการ CHECK หรือเก็บ IP และ AGENT ของเครื่องที่เล่น เพื่อใช้เป็นตัวแปรหนึ่งในการ AUTHEN เข้าระบบ จะได้ไหมครับ น่าจะป้องกันได้อีกครับ จากคุณ : M|B เขียนเมื่อ : 3 ธ.ค. 54 06:58:45

ความคิดเห็นที่ 16 ถ้าเจ้าของผู้ใช้งานไม่ส่ง link ไปให้ Click ก็จะเข้าไม่ได้ครับ ถ้าเจ้าของ logout ออกแล้ว แม้มี link อยู่ก็กดต่อไม่ได้ครับ ถ้าเจ้าของ login เข้าใช้ใหม่ link เดิมที่มีอยู่ก็ใช้ไม่ได้แล้วครับ แม้ผ่านข้างบนมาทั้งหมด กด ไปหน้าทำรายการ ซื้อ หรือขาย ได้ ก็จะยืนยันขั้นตอนสุดท้ายไม่ได้ครับ เนื่องจากจะมีการตรวจสอบทางหลังบ้านเพิ่มด้วยครับ สุดท้ายที่กำลังจะดำเนินการเข้ารหัสเพิ่มขึ้นเพื่อไม่ให้ทราบข้อมูลใน link ครับ จากคุณ : pjuk เขียนเมื่อ : 3 ธ.ค. 54 07:21:48

ความคิดเห็นที่ 17 ชอบคุณครับคุณ pjuk อธิบายอะไรได้รวบรัดและชัดเจนดีครับ เป็นคุณสมบัติของคนที่่ทำงานบริหารสามารถมอบหมายงานได้ชัดเจนดี จากคุณ : pimmuno เขียนเมื่อ : 3 ธ.ค. 54 08:10:30

ความคิดเห็นที่ 18 พี่จุกครับ ขอแสดงความเห็นนะครับ ขอพูดตรงๆนะครับ ถ้าในวงการ security สิ่งที่เกิดขึ้นนี้ จะ consider ว่าไม่ปลอดภัยครับ ถ้าหากคุณคิดว่า ถ้าเจ้าของไม่ส่ง link ให้ก็เข้าไม่ได้ แบบนี้ไม่ถูกต้องเสมอไปครับ บางครั้ง link หรือ session id สามารถถูกโขมยได้โดยการใช้ malicious script เทคนิคที่ใช้การอย่างแพร่หลาย ในการ hack web app คือ XSS, CSRF. การที่บอกว่า logout แล้วก็ไม่มีใครทำไรได้นั่นถูกครับ แต่เทคนิคที่เค้า hack กันทั่วโลกที่ฮิตๆ ค่ือการขโมย session id ไป เพื่อให้ได้ session (เหมือนกรณีนี้) แล้วก็ทำธุรกรรมในทันทีครับ (hacker มันไม่รอให้คุณ logout หรอกครับ) อีกเรื่องเกี่ยวกับ https นั้นไม่ได้ช่วยในเรื่องป้องกัน web app hacking นะครับ มันช่วยแค่ป้องกันการดักฟังข้อมูลตอนส่งผ่าน network ในวงการ security นะครับ ต่อให้ hacker ยังเจาะไม่ได้ แต่ยอมให้สิ่งเหล่านี้เกิดขึ้นถือว่ามีความเสี่ียง(สูง)ครับและผมว่ามันค่อนข้าง unacceptable (แรงไปไหม?) web app audit เซ็นให้ผ่านเหรอครับเคสแบบนี้ สิ่งที่ยังพอทำให้อุ่นใจอยู่บ้างคือมีการ validate ที่ backend (หวังว่าคง validate อย่างดีนะครับ) แล้วก็ solution ที่บอกจะทำนี่ผมว่ามันแก้ปัญหาไม่ตรงจุดนะครับ ต่อให้เข้ารหัสยังไง ผมดู url/parameter ไม่รู้เรื่อง  ผมก็ยังเอา link ไปใช้ได้อยู่ดี วิธีแก้ไขปัญหานี้ ก็ไป google ดูละกันครับแล้วจะรู้ว่านี่มันเป็นปัญหา basic ที่ใครทำงานด้านนี้ก็จะรุ้จัก และจะทราบว่ามันต้องทำการป้องกัน keyword ที่ใช้ search ก็ "Session fixation" ก็ได้ครับเพราะมันถือว่าเป็นเทคนิคย่อยๆเกี่ยวกับ session fixation ป.ล.แต่ถ้าไม่รู้จริงๆ ก็หลังไมมานะครับจะช่วยบอกให้ (แลกกับค่าธรรมเนียมจัดการกองทุน - ล้อเล่นครับ) ที่พูดเพราะหวังดีครับ ผมก็ลูกค้า รบกวนไปพิจรณาปรับปรุงด้วยครับ ป.ล. edit เพราะ แก้ไขให้อ่านง่าย + เพิ่มเติมข้อมูลนิดหน่อย แก้ไขเมื่อ 03 ธ.ค. 54 11:19:24 แก้ไขเมื่อ 03 ธ.ค. 54 09:56:54 จากคุณ : test (^pop^) เขียนเมื่อ : 3 ธ.ค. 54 09:53:34

ความคิดเห็นที่ 19 ขนาดไม่มีช่องก็ยังพยายามเจาะรู แล้วประสาอะไรกับการที่มีรูอยู่แล้วผู้ไม่หวังดีจะไม่พยายามหาทางเพื่อให้เข้าผ่านรูนั้นไปได้ จากคุณ : Never Be The Same Again เขียนเมื่อ : 3 ธ.ค. 54 10:27:11

ความคิดเห็นที่ 20 ผมว่าข้อมูลระดับ highly confidential ไม่ควรหลุดไปได้แบบนี้นะครับ ถึงแม้จะทำรายการไม่ได้ แต่ก็สามารถทำให้ข้อมูลอื่นๆถูกเปิดเผยได้ ซึ่งไม่ปลอดภัยในทาง Security (ไม่รู้ว่าสามารถนำข้อมูลนั้นไปใช้ประโยชน์อะไรได้อีกบ้าง ?) อาจจะโดยผู้ใช้เองเป็นผู้ทำให้ระบบไม่ปลอดภัย แจ่ระบบที่ดีกว่านั้นควรจะป้องกันภัย / มีความปลอดภัยของข้อมูลให้มากที่สุดเท่าที่จะมากได้หรือไม่ครับ ปล.ผมไม่รู้ว่าหลังบ้านจากนั้นมีการทำ Authentication อะไรเพิ่มอีก และ Auth ดีแค่ไหนครับ ส่วนของกองทุน(ซื้อขาย) มี Auth. เพิ่มเติมด้วยหรอครับ เคยซื้อ(เมื่อก่อน)แล้วกดผ่านๆไปได้เรื่อยๆ ไม่มี OTP หรืออะไรให้เล่นหรือเปล่าครับ แก้ไขเมื่อ 03 ธ.ค. 54 11:00:22 จากคุณ : มิ่งกลิ้ง เขียนเมื่อ : 3 ธ.ค. 54 10:59:47

ความคิดเห็นที่ 21 ดีครับ เวปจะได้ปลอดภัยมากยิ่งขึ้น ปล. รุสึกกลัวๆ เหมือนกันส่ง sessionID ผ่าน _GET โต้งๆ แบบนี้ จากคุณ : หมึกสด เขียนเมื่อ : 3 ธ.ค. 54 11:14:49

ความคิดเห็นที่ 22 SCB ช่วยดำเนินการแก้ไขและออกมาชี้แจงด้วยครับ เริ่มหวั่นๆและไม่เชื่อถือในระบบความปลอดภัยแล้วครับ จากคุณ : kusen เขียนเมื่อ : 3 ธ.ค. 54 11:29:44

ความคิดเห็นที่ 23 ^ ^ ^ consider unacceptable ศัพท์เฉพาะในวงการเหรอ จากคุณ : ฉลาดหน้าตาดีมีเงินใช้ เขียนเมื่อ : 3 ธ.ค. 54 11:36:10

ความคิดเห็นที่ 24 คห 23 ต้องขอโทษทีครับที่พิมไทย สลับ eng มันติดเป็นนิสัยหนะครับ ผมพยามหาคำที่มันไม่ agressive อะครับ บางคำพิมเป็น eng จะ soft กว่า (ความรู้สึกส่วนตัว) แก้ไขเมื่อ 03 ธ.ค. 54 12:26:48 จากคุณ : test (^pop^) เขียนเมื่อ : 3 ธ.ค. 54 12:25:39

ความคิดเห็นที่ 25 โอ้ เงิน เป็นหลัก หลายล้าน ทำกันง่ายกว่า โปรเจคจบผมซะอีก ^ ^ จากคุณ : peboybad เขียนเมื่อ : 3 ธ.ค. 54 14:40:43

ความคิดเห็นที่ 26 วันอังคารนี้ คงจะได้ easy กันแบบ รวดเร็ว และมั่นคง แล้วกระมังครับ มีเวลาให้ทำงานแก้ไข ตั้งหลายวัน จากคุณ : กุ้งเต้นชามะนาว เขียนเมื่อ : 3 ธ.ค. 54 21:07:14

ความคิดเห็นที่ 27 แก้เถอะครับ ผมก็ใช้อยู่  รู้ช่องโหว่ขนาดนี้ hack ไม่ยากเลยครับ จากคุณ : TIBWorld เขียนเมื่อ : 4 ธ.ค. 54 01:07:36

ความคิดเห็นที่ 28 เดียวก็เข้าไปทำธุรกรรมทางการเงินไม่ได้อีกหลายวันแบบอาทิตยืก่อนหรอก 55555555555 เกือบแย่ เวปธนาคารระดับประเทศ บอกให้งานเยอะๆ แต่เจ๊งนานแบบนี้ - - " จากคุณ : kopbirt เขียนเมื่อ : 4 ธ.ค. 54 06:24:21

ความคิดเห็นที่ 29 ตอนนี้ใช้ easy fund ไม่ได้ แล้วครับ ใครใช้ได้บ้าง ... จากคุณ : pornchal เขียนเมื่อ : 4 ธ.ค. 54 07:14:32

ความคิดเห็นที่ 30 ขอบคุณ คห.16 pjuk ที่ช่วยดำเนินการอยางรวดเร็็ว และ ขอบคุณ คห.18 test (^pop^) ที่ช่วยชี้ให้เห็นช่องโหว่ เพื่อการพัฒนาระบบความปลอดภัย user อย่างผมจะได้ใช้อย่างปลอดภัย สบายใจครับ จากคุณ : blackflame เขียนเมื่อ : 4 ธ.ค. 54 12:48:31

ความคิดเห็นที่ 31 สิ่งที่พวกเราคนใช้เว็บธนาคารทำได้คือเข้าโหมด Private หรือ Incognito ก่อนทำธุรกรรมทุกครั้งครับ แต่ข้อเสียอย่างเดียวคือต้องแลกมาด้วยการป้อนพาสเวิร์ดซึ่งจริง ๆ ก็เป็นสิ่งที่ควรทำมากกว่าเอาไปจำไว้ในเครื่องอยู่แล้วนะครับ --------------------------------------------- ผมเข้าใจมุมมองของคนที่ปล่อย token ให้อยู่บน url นะครับ เพราะ "ทางเทคนิค" เอาไปไว้ใน cookie หรือปล่อยไว้บน url มันก็เหมือนกัน     ถ้าเป็น clear text มิลเดิลแมนก็เห็นเหมือนกัน     ถ้าเป็น secure tunnel มิดเดิลแมนก็ไม่เห็นเหมือนกัน แต่ผมเห็นเหมือนท่านอื่น ๆ นะครับว่าปลอดภัย "ทางเทคนิค" ตามตำรา อย่างเดียวคงไม่พอครับ ตราบใดที่ token สามารถก๊อบปี้ง่าย ๆ แค่ (หลอกให้) กด Ctrl+C มันก็เป็นสิ่งที่ล่อตาล่อใจ Social Engineering นักนะครับ จริงอยู่ เอาไปไว้ในคุกกีมันก็ Ctrl+C ได้ แต่อย่างน้อยก็ต้องเข้าไปหลาย ๆ Dialog กว่าจะถึงนะครับ อีกอย่างในวิกิพีเดียบอกไว้อย่างชัดเจนว่า ระบบ "ส่วนใหญ่" เอาไปไว้ในคุกกี้แล้วนะครับ ถึงแม้ว่าจะเป็นความเห็นส่วนตัวของคนเขียนบทความ (ไม่มี citation) ก็ตาม แต่คุณว่ามันถูกของเค้าไหมล่ะครับ เพราะยุคนี้เราไม่ได้ต่อสู้กับ middle man เท่านั้นแต่สู้กับ social engineering กันแล้วไม่ใช่เหรอครับ --------- จากวิกิพีเดีย http://en.wikipedia.org/wiki/Session_fixation Solution: Store session identifiers in HTTP cookies The session identifier on most modern systems is stored by default in an HTTP cookie, which has a moderate level of security as long as the session system disregards GET/POST values.[citation needed] However, this solution is vulnerable to cross-site request forgery. จากคุณ : sandthorn เขียนเมื่อ : 4 ธ.ค. 54 14:43:29

ความคิดเห็นที่ 32 น่ากลัว ป้องกันด่วนครับ SCB จากคุณ : Gunner_Noy_Skywalker_5 เขียนเมื่อ : 4 ธ.ค. 54 21:52:34

ความคิดเห็นที่ 33 เวรกรรมครับท่าน ท่านทำเว็บไม่ใส่ใจกันขนาดนี้เลยเหรอ เรื่องนี้มัน Common Sense ของ Security เลยนะครับ จากคุณ : ผมไม่ได้เป็ด เขียนเมื่อ : วันพ่อแห่งชาติ 54 01:49:34

ความคิดเห็นที่ 34 Session tokens should never be transmitted in the URL, because this provides a simple vehicle for session fixation attacks and result in tokens appearing in numerous logging mechanisms. In some cases, developers use this technique to implement sessions in browser that have cookies disabled. However, a better means of achieving this is to use POST requests for all navigation and store tokens in a hidden field of an HTML form. จากหนังสือ The Web Application Hacker's handbook 2 จากคุณ : ^pop^ เขียนเมื่อ : วันพ่อแห่งชาติ 54 11:28:41

ความคิดเห็นที่ 35 ^ ^ ^ กลับมาอ่านกระทู้นี้อีกครั้ง เห็นมีประเด็นเรื่องการส่ง Token ว่าไม่ควรส่งผ่าน GET ควรส่งเป็น POST ผมสงสัยอยู่อย่า 1 ว่า การส่งแบบ GET หรือ POST แตกต่างกันอย่างไรครับ ยอมรับครับว่า GET มันเห็นโต้งๆเลยว่าส่งอะไรไป แต่ POST ก็เดาได้เหมือนกันหนิครับว่าส่งอะไรไป เพราะสิ่งที่ POST ไป ก็คือสิ่งที่อยู่บน HTML FORM เหมือนกัน ถึงแม้ว่าจะปกปิดด้วย JAVA SCRIPT ได้ แต่ JAVA SCRIPT ก็เป็น Client Side Script เหมือนกัน HACKER ก็ไล่ได้ว่า สิ่งที่ส่งไปคืออะไร อย่าง Drupal ที่ทำ Form Authen ด้วย ผม View Source ก็รู้แล้วว่า Token มันคืออะไร เลยอยากถามว่ามี Case ไหนบ้างไหมที่การส่ง แบบ POST จะปลอดภัยกว่า GET แบบ 100% เช่นใน CASE นี้ GET โดน HACK แน่ๆ แต่ POST ไม่โดน แบบนั้นครับ จากคุณ : M|B เขียนเมื่อ : วันพ่อแห่งชาติ 54 18:19:02

ความคิดเห็นที่ 36 ทำไม ผมอ่านแล้วไม่กลัวเลยนะนี่ จุดที่หลวมไปไม่ใช่ การควบคุมหลักเลยครับ ยังกันที่อื่นอีกเยอะ จากคุณ : Laganus เขียนเมื่อ : วันพ่อแห่งชาติ 54 21:36:57

ความคิดเห็นที่ 37 ทำไมยังต้องใช้วิธีการส่งผ่าน Query String อยู่อีก โปรแกรมเมอร์ห่วยไปมั้ยครับ จากคุณ : bodyseries เขียนเมื่อ : วันพ่อแห่งชาติ 54 21:43:52

ความคิดเห็นที่ 38 คุณ M|B ก่อนอื่นเลยต้องบอกว่าส่งแบบ post ก็ไม่ได้ปลอดภัยครับ ก็ยังสามารถโดนทำ session hijacking โดยใช้เทคนิค XSS (Cross-site script)และ อื่นๆ ได้ครับ สาเหตุหลักๆ(เท่าที่ผมทราบ)ที่ไม่ควรแปะ session id ไปกับ url ก็คือ 1. เป็นปัญหาที่เจ้าของกระทู้พบเจออยู่นี่แหละครับ คือคนอื่นเอาไปเปิดได้เลย 2. แปลจากประโยคนี้เลยนะครบ "because this provides a simple vehicle for session fixation attacks"   ก็หมายความว่ามันเป็น "เครื่องมือ" ซึ่งสามารถนำไปสู่ช่องโหว่ที่เรียกว่า session fixation เมื่อมีการส่ง session id ไปกับ get parameter นั่นหมายความว่าฝั่ง server ต้องเขียน code เพื่อรับค่านี้ไปใช้งาน ถ้าหากโปรแกรมเมอร์เขียนโปรแกรมจัดการ parameter ตัวนี้ไม่ดี ก็จะทำให้เกิดการขโมย session ได้ ลองดู simple scenario การทำ session fixation ได้จากที่นี่ก็ได้ครับ http://en.wikipedia.org/wiki/Session_fixation หรือดูรูปที่ผมแปะก็ได้ครับ 3. สาเหตุข้อนี้ก็อ้างหนังสืออีกเช่นเคย "this result in tokens appearing in numerous logging mechanisms" ซึ่งหมายความว่า เมื่อ session id อยู่ที่ url แล้ว เวลามีคนกดคลิ๊กเนี่ย ส่วนใหญ่มันจะไปลง log file ต่างๆ ลองนึกดูครับ url ที่มี session id แปะอยู่ไปโผล่ใน log file ถ้า hacker เข้าถึง log file ได้ก็จบครับ เหมาหมดทุก session ด้วยเหตุผลทั้ง 3 ข้อนี้ ผู้เชี่ยวชาญจึงสรุปออกมาได้ว่ามันมีความเสี่ยง ส่วนวิธีการป้องกันนั้นไม่ได้ต้องการ การ investment ที่สูงนัก เพราะฉะนั้นมันคุ้มค่าที่จะป้องกัน จากคุณ : test (^pop^) เขียนเมื่อ : วันพ่อแห่งชาติ 54 22:42:10

ความคิดเห็นที่ 39 ก่อนอื่นเลยผมไม่อยากให้ทุกท่านคิดว่า programmer ห่วยหรืออะไรนะครับ คน design ระบบเค้าน่าจะมีเจตนาอะไรบางอย่างที่ทำแบบนี้ครับ เหตุผลนึงที่คิดได้ก็คือ เค้าต้องการให้ user ที่ disable cookie สามารถใช้งานเว็บได้ครับ ประวัติความเป็นมามันยาวนานครับ internet เนี่ย เมื่อยุคนึงสมัยนึง ที่ web app ยังไม่บูมเหมือนตอนนี้ บางช่วงเวลาเค้าก็แนะนำให้ turn of Javascript and cookie ครับเพื่อความปลอดภัย แต่พอมาถึงสมัยนี้แล้วเนี่ย ใคร turn off Javascript and cookie ก็คงใช้งานเว็บส่วนใหญ่ไม่ค่อยได้ครับ สุดท้ายนี้ เมื่อยุคสมัยเปลี่ยนไป ระบบก็ต้องมีการพัฒนาตามอย่างสม่ำเสมอครับ web app ที่ผมดูแลอยู่ enhance กันทั้งปีครับ จ้างบริษัท hacker มา hack ทุกครึ่งปีครับ ผมไม่เคยทำ bank thai ครับ แต่แอบหวังลึกๆว่าเค้าคงมีมาตรฐานนี้เหมือนกันมั้ง จากคุณ : test (^pop^) เขียนเมื่อ : วันพ่อแห่งชาติ 54 22:51:21

ความคิดเห็นที่ 40 ถ้าให้ดีล่ะ ฝั่ง Client ก็ส่งค่าให้ Server เข้ารหัสไว้ ด้วย Key ตัวหนึ่ง จากนั้นเวลาถอนรหัสก็ใช้ key มาถอดไม่ดีกว่าหรือ เป็น public and private key หรือ single key ในการถอด เข้ามันแบบนี้ แต่สิ่งที่เกิดคำถามคือ คุณเข้ารหัสไปทำใ้ห้เครื่อง Server และ Client ทำงานหนักขึ้นกว่าเดิม เพื่อข้อมูลที่มีความสำคัญมากขนาดนั้น อีกอย่างคือ Web Admin ที่ดูแลระบบที่ใช้เช่น IIS หรือ Apache นั้น ตั้ง Time out ต่ำไปหรือไม่ หรือเปล่า ถ้าตั้งเป็น 15 นาทีได้หรือไม่ หรือ 10 นาทีไม่ใช่งานให้ log out ออก หรือน้อยกว่านั้นได้หรือไม่ เพียงพอที่ผู้ใช้งานนั้นใช้งาน หรือถ้าหากเปลี่ยนหน้าก็นับ time out ใหม่ด้วย บ้างครั้ง website ดังกล่าวเขียนด้วยระบบ OS ตัวเก่า ต้องรื้อด้วย คำถามเกิดว่า รื้อระบบเพียงเรื่องแค่นี้คุ้มค่าหรือเปล่า แล้วบริษัทต้องลงทุนเพิ่มขึ้น เพื่ออะไร อันนี้คือ Worst Case เลย เพราะ IIS หรือ apache มันก็ขึ้นกับระบบปฏิบัติการเหมือนกัน ทุกอย่างมีแนวทางแก้ไข แต่ดำเนินการแก้ไขโดยใช้แนวทางไหนเท่านั้นเองล่ะ ปล งานนี้ Programmer คงปวดหัวหาทางออกอยู่ แต่จริงๆ มันต้องคุยกันหมดทั้ง Programmer Admin และผู้ที่สามารถทุบโต๊ะเพื่อจบได้ :) จากคุณ : Myth&Miracle เขียนเมื่อ : วันพ่อแห่งชาติ 54 23:10:47

ความคิดเห็นที่ 41 ขอตอบคำถามคุณ Myth&Miracle ค่า parameter ที่ส่งไปมีการ เข้ารหัสแล้วครับ แต่ปัญหาคือ โดนขโมย (หรือดักฟัง) ผมลับจากการเข้ารหัสระหว่างทางครับ และจากคำตอบที่ ความคิดเห็นที่ 38 ที่ทางคุณ test (^pop^) อธิบายไว้ว่า การใช้ GET PARAMETER ทำให้เห็นพวกผลลัพธ์จากการเข้ารหัสง่ายเกินไปครับ จากคุณ : M|B เขียนเมื่อ : วันพ่อแห่งชาติ 54 23:28:03

ความคิดเห็นที่ 42 อย่างไรก็ดี คงต้องถอนเงินออกจากบัญชีให้เหลือน้อยที่สุดแล้วไปใช้ธนาคารอื่นก่อนดีกว่า.    ขอถามหน่อยครับว่าระบบความปลอดภัยของธนาคารไหนดีที่สุดครับ จากคุณ : Fuweng เขียนเมื่อ : 6 ธ.ค. 54 07:44:26

ความคิดเห็นที่ 43 ก่อนอื่น SCB ต้องปรับวิธีคิด และรีบ ยกปัญหานี้ ขึ้นเป็นปัญหาที่ต้องแก้ไขอย่างเร่งด่วน ก่อนครับ จากคุณ : รูปเงาะเดินสบาย เขียนเมื่อ : 6 ธ.ค. 54 08:41:45

ความคิดเห็นที่ 44 เห็นใจทีมโปรแกรมเมอร์ สู้ๆนะคะ จากคุณ : นางฟ้าของก้อนหิน เขียนเมื่อ : 6 ธ.ค. 54 09:47:36

ความคิดเห็นที่ 45 ช่วยอุดรูโหว่ตรงจุดนี้ด้วยครับ จากคุณ : นายฉิม เขียนเมื่อ : 6 ธ.ค. 54 11:02:30

ความคิดเห็นที่ 46 pjuk ตกไปประโยคนึง สุดท้ายของสุดท้าย ขอบคุณทุกท่านที่ชี้ช่องโหว่ จากคุณ : PET3R.Pan เขียนเมื่อ : 6 ธ.ค. 54 11:35:16

ความคิดเห็นที่ 47 ในฐานะคนพัฒนา ebanking ให้แบงค์แห่งนึง ลูกค้าจ้าง บ. แห่งนึง มาทำ Vulnerability Assessment เจอเคสแบบนี้เหมือนกันครับ - ผลคือไม่ควรมีกรณีแบบนี้เกิดขึ้นครับ ถึงในแง่ของข้อมูลฝั่ง Server จะมีการ Validate แต่การที่เปิดโอกาสให้เห็นข้อมูลสำคัญ ถือว่าส่งผลในแง่ของความเชื่อมั่นในระบบ จากคุณ : developer เขียนเมื่อ : 7 ธ.ค. 54 00:26:10

ความคิดเห็นที่ 48 จากข้อมูลข้างต้น ไม่น่าจะส่งค่า session id ไปกับ link  น่าจะทำการ login แล้ว server ใช้ค่านึงติดต่อกับ client คือ scode มากกว่า ซึ่งในการติดต่อกับ server แต่ละที จะทำการ update scode ตัวนี้ว่ายังติดต่อได้ภายในกี่นาที ปกติ 20 นาทีหรือทำการ logout ก็ clear ค่าว่า scode ตัวนี้ใช้ไม่ได้ แต่ที่ดูแล้วแต่ละ request url อยู่ภายใต้ domain เดียวกัน กลับต้องใช้ scode ในการติดต่อ ผมมองว่า Easy Fund น่าจะเป็นคนละระบบกับตัวหลัก (คนละ domain ไปเลย) หรือทำหลายคน คนละ module แต่ทำพร้อมกัน ถ้าเป็นแบบหลัง แต่ใช้วิธีคุยกันแบบนี้ ก็ถือว่าแย่มาก แต่ถ้ามองในแง่ security แล้ว ยังไงก็ไม่ผ่าน audit ไปได้ ถาม #16 ที่บอกว่าจะเข้ารหัสไม่ให้รู้ข้อมูลภายใน link แล้วจะส่งค่าที่ไม่จำเป็นมาทำไมครับ server ก็รู้อยู่แล้วว่า login นี้มีข้อมูลอะไรบ้าง จากคุณ : massacre เขียนเมื่อ : 7 ธ.ค. 54 02:04:00

ความคิดเห็นที่ 49 ปกติธนาคารจะต้องมีการทำ Security Audit ก่อนที่จะ Launch ขึ้น Production ไม่รู้ว่าทำไม ส่วนนี้ถึงหลุดออกมาได้?  คงต้องรอทีมที่ีเกี่ยวข้องออกมาชี้แจ้งครับ จากคุณ : flyingbuff (flyingbuff) เขียนเมื่อ : 7 ธ.ค. 54 07:58:07

ความคิดเห็นที่ 50 พลาดตั้งแต่พื้นฐานของ HTTP Protocol แล้ว ต้องแยกความแตกต่างระหว่าง POST กับ GET ก่อน  GET ใช้สำหรับดึงข้อมูลมาแสดงผลเท่านั้น POST ใช้สำหรับส่งข้อมูลไปประมวลผล โดยจะร้างหรือปรัปปรุงข้อมูลบนเป้าหมาย ดูจากการทำงานของเว็บแล้ว การใช้ Method GET ในการดึงข้อมูลมาแสดงผลจึงเป็นสิ่งที่ถูกต้องแล้ว แต่สิ่งที่พลาดอย่างแรงคือการส่งข้อมูลอื่นๆ ที่ไม่จำเป็นกับการทำงานไปด้วย ในเมื่อสามารถใช้ Cookie เก็บ Session Token ได้ ข้อมูลอื่นๆก็สามารถ Process บน Server ได้  จากคุณ : kowito เขียนเมื่อ : 7 ธ.ค. 54 08:44:05

ความคิดเห็นที่ 51 กระทู้นี้เจ๋งอ่ะ เหมือนได้กลับไปเรียน web programming อีกรอบ จากคุณ : หมึกสด เขียนเมื่อ : 7 ธ.ค. 54 09:37:05

ความคิดเห็นที่ 52 ไม่นิ่งนอนใจ จัดการแก้ไขปรับปรุงปรับเปลี่ยนภายในเดือนนี้ต้องมีการเปลี่ยนแปลงครับ .... ขอบคุณทุกแนวคิด ขอบคุณทุกแนวทาง ที่จะทำให้ SCB Easy Net พัฒนาต่อไปครับ จากคุณ : pjuk เขียนเมื่อ : 7 ธ.ค. 54 10:54:24

ความคิดเห็นที่ 53 ขอบคุณพี่จุกครับ ที่รับฟัง แล้วช่วยประสานงานในการ ปรับปรุง จากคุณ : test (^pop^) เขียนเมื่อ : 7 ธ.ค. 54 11:35:29

ความคิดเห็นที่ 54 ขอบคุณมากๆ ครับ จะรอดูการพัฒนาของ SCBeasy ครับ ^^' จากคุณ : worldicez เขียนเมื่อ : 7 ธ.ค. 54 11:52:35

ความคิดเห็นที่ 55 เข้ามางง จากคุณ : Godgate เขียนเมื่อ : 7 ธ.ค. 54 12:11:42

ความคิดเห็นที่ 56 #52 ขอบคุณที่ปรับปรุง แต่ว่าจะทำอย่างไรกับคนที่แบกความเสี่ยงในการรอการแก้ไขในช่วงเวลานี้ แบกความเสี่ยงเองไปเรื่อยๆหรือเปล่า? จากคุณ : kowito เขียนเมื่อ : 7 ธ.ค. 54 14:06:15

ความคิดเห็นที่ 57 วิธีการส่งผ่านค่าผ่านทาง query string แบบนี้เขาเลิกใช้กันตั้งแต่ 3 ปีที่แล้ว แล้วครับ เนื่องจากไม่ค่อย secure เท่าไหร่ ถึงแม้จะเข้ารหัสไว้แต่ไม่มีรหัสแบบ ไหนหรอกครับที่ถอดไม่ได้ โดยมากปัจจุบันจะใช้ session เข้าเก็บค่า parameter ต่างๆ แทน โดยไม่ฝาก session id ไปกับ url น่าจะปรับปรุงสักหน่อย ผมลองทดสอบแล้วจาก account ของตัวเองก็สามารถนำ ลิงค์ไปเปิดอีกเครื่องหนึ่งได้โดยไม่ต้อง login เลย สามารถดูข้อมูลกองทุนหรือ ข้อมูลต่างๆ ได้ แต่ตอนนี้ต้องเข้าใจว่าความเสี่ยงที่เกิดขึ้นตอนนี้จะเกิดขึ้นกับคนที่ใช้คอมพิวเตอร์ สาธารณะในการทำธุรกรรมกับธนาคารเท่านั้น ถ้าเครื่องตนเองไม่น่าจะมีปัญหา แค่ logout ออกหลังการใช้งานทุกครั้ง และอย่าให้คนที่ไม่รู้จักมารให้เครื่อง ตนเองก็ป้องกันได้บางส่วน วิธีการง่ายๆ ในการปกป้องตัวเอง อย่างผมใชัเปิดบัญชีซ้อน บัญชีที่ผมเก็บเงิน จะไม่มีการผูกกับ atm หรือ internet banking เลย ใช้ฝากถอนปกติ แต่บัญชีใช้จ่ายปกติจะมี atm และต่อกับ internet banking เพื่อความ สะดวกในการใช้งาน แค่นี้ก็ไม่ต้องกังวลมากครับ จากคุณ : Matsuo Masahiro (Matsuo Masahiro) เขียนเมื่อ : 7 ธ.ค. 54 17:04:13

ความคิดเห็นที่ 58 ยกเลิกที่ป้องกันคลิกขวาด้วยนะครับ pjuk มันไม่ได้ช่วยเพิ่มความปลอดภัยอะไรเลยนะครับ มีแต่น่ารำคาญซะมากกว่า จากคุณ : oppertunity เขียนเมื่อ : 7 ธ.ค. 54 20:00:51

ความคิดเห็นที่ 59 เป็นกระทู้ที่ให้ความรู้มากค่ะ จากคุณ : mapraow เขียนเมื่อ : 7 ธ.ค. 54 21:36:13

ความคิดเห็นที่ 60 คหที่ 57 ขอแย้งนะครับ เดียวคนอ่านเจอ จะกังวลกันไปใหญ่ "วิธีการส่งผ่านค่าผ่านทาง query string แบบนี้เขาเลิกใช้กันตั้งแต่ 3 ปีที่แล้ว แล้วครับ เนื่องจากไม่ค่อย secure เท่าไหร่" ประเด็นแรก การส่งค่าผ่านทาง query string ปัจจุบันยังใช้ได้อยู่นะครับ ไม่ได้เลิกใช้ อย่าง hotmail ยังใช้อยู่เลย เล่นผมอ่าน mail 1 อันของ hotmail url ผมเปลี่ยนเป็น http://sn114w.snt114.mail.live.com/default.aspx#!/mail/InboxLight.aspx?n=951865057!fid=1&fav=1&n=1774595363&mid=efe19672-1039-11e0-b084-002264c2c1bc&fv=1 สำหรับคนที่มือใหม่เรื่อง web programming ตัวอักษรที่อยู่หลังเครื่องหมาย ? เขาเรียนว่าเป็น query string ซึ่งเป็นข้อมูลที่ส่งไปยัง server หรือแม้กระทั้งอันนี้ (คงเดาออกนะว่าของเจ้าไหน) https://ebank.kasikornbankgroup.com/retail/cashmanagement/BillPayment.do?action=begin&spTypeId=20030210000000&spId=117 อีกอันที่ขอแย้งคือ "ไม่มีรหัสแบบไหนหรอกครับที่ถอดไม่ได้" ประโยคนี้จริงเป็นบางส่วน ที่ผิดคือ มันใช้เวลาเป็นแรมเดือนในการคำนวน เพื่อถอดรหัสครับ แถมยังไม่รู้เลยว่า รหัสที่ถอดมาถูกหรือเปล่า เพราะสมัยนี้ เขาใส่ salt หรือว่าสิ่งปลอมปน ลงไปด้วย ทำให้ต้องมาเลือกอีกว่า byte ไหนที่เป็นข้อมูลจริงๆ หรือ byte ไหนเป็นสิ่งปลอมปน ดังนั้นมันไม่ถอดได้ภายใน 10 นาที ให้เขานำ ticket หรือที่เรียกง่ายๆว่าบัตรผ่านเข้าใช้งาน ของคุณไปใช้หรอกครับ สุดท้ายนี้ ก็ขอให้ทุกคนกด logoff เมื่อใช้งานเสร็จครับ จริงๆกระทู้นี้เบี่ยงประเด็นมาเยอะละ ถ้าอ่านความตั้งใจของ จขกท จริงๆ เขาแค่สงสัยว่าทำไม มันเปิดพร้อมกันได้หลายที่แค่นั้นเอง จากคุณ : M|B เขียนเมื่อ : 7 ธ.ค. 54 22:18:59

ความคิดเห็นที่ 61 ดีจังครับกระทู้นี้ ได้ย้อนความรู้เดิมบางอย่างที่ลืมไปแล้ว  ได้รับความรู้ใหม่เพิ่มเติมเข้ามา จากคุณ : netaddict เขียนเมื่อ : 8 ธ.ค. 54 09:54:41

ความคิดเห็นที่ 62 คุณ M|B พูดขึ้นมาเลยนึกได้ หวังว่า password เนี่ย scb คง hash แล้วก็ salt ก่อนที่จะเก็บลง db นะครับ ถ้าไม่ salt ละก็แย่เลยเจอ brute force คงไม่รอด จากคุณ : test (^pop^) เขียนเมื่อ : 8 ธ.ค. 54 13:23:08

ความคิดเห็นที่ 63 สงสัยครับ เห็นข้อมูลแล้วเอาไปทำอะไรได้หรือครับ ? เพราะยังไงก็ไปซื้อ-ขายแทนไม่ได้อยู่ดี เพราะมีหลังบ้านตรวจสอบอีกครั้ง ? ไม่เคยเล่น easyfund กะเขาซะด้วย - -' จากคุณ : gluttony เขียนเมื่อ : 8 ธ.ค. 54 21:12:01

ความคิดเห็นที่ 64 ^ ^ ถ้า Copy Link ไปได้ แล้วนำ link นั้นไปใช้หลังจากที่คนใช้คนก่อนเลิกใช้ แต่ยังไม่ logout และไม่เกินประมาณ 10 นาที คนที่ Copy ไป สามารถจะสั่งซื้อกองทุน สั่งขายกองทุน สลับกองทุนได้หมดครับ โดยไม่จำเป็นต้องทำที่เครื่องเดียวกับที่เจ้าของใช้งานครับ จากคุณ : M|B เขียนเมื่อ : 8 ธ.ค. 54 22:52:37

ความคิดเห็นที่ 65 ขอถามต่อแบบไม่ค่อยจะรู้เรื่องคอมนะครับ ถึงจะโดนเข้ามาขโมยข้อมูลไปซื้อขายสับเปลี่ยนกองทุนไปยังไง  แต่เงินก็ยังอยู่ในบัญชีของเราไม่ใช่หรอครับ? ก็เห็นบอกว่าเปนเฉพาะที่ตัว easy fund ถ้าทำได้แค่นั้น แล้วเค้าจะขโมยข้อมูลไปทำอะไร? จากคุณ : ตะวันทะยานฟ้า เขียนเมื่อ : 9 ธ.ค. 54 15:09:05

ความคิดเห็นที่ 66 คุณ ตะวันทะยานฟ้า ไม่ต้องถูกโอนเงินไปหรอกครับ แค่กดเค้ามาเห็นเงินที่คุณ ลงทุนอยู่ หรือ ถ้าแย่กว่านั้นคือสับเปลี่ยนกองทุน คุณเล่นๆ ถามว่า คุณรับได้ไหมครับ ที่มีคนเข้ามาดูข้อมูล หรือ ยุ่มย่ามกับสิ่งที่ควรจะเป็นความลับ จากคุณ : test (^pop^) เขียนเมื่อ : 9 ธ.ค. 54 16:45:49

ความคิดเห็นที่ 67 ปกติเค้าต้อง Penetration test กันทุกปีไม่ใช่เหรอครับ ไม่น่าหลุดได้ จากคุณ : kobkab เขียนเมื่อ : 9 ธ.ค. 54 21:19:54

ความคิดเห็นที่ 68 อ่านกระทู้นี้แล้วเครียดค่ะ  ถึงเราจะมีจำนวนเงินไม่เยอะล่อตาล่อใจแฮ้คเกอร์ทั้งหลาย แต่ก็อยากให้ทาง scbeasy หาทางอุดช่องโหว่โดยด่วนคะ จากคุณ : บ่าบี๋ เขียนเมื่อ : วันรัฐธรรมนูญ 54 10:32:34

ความคิดเห็นที่ 69 }}}}}} }}}}}}}}}}}} น่าสนใจ   แฮะ .... อย่างนี้  ใช้ ช่อง ทางนี้...เข้าไปดู ข้อมูล หุ้น ของลูกค้า ..ทั้ง บล   และ  บลจ... ไปดูต้นทุน  ที่  ลูกค้า  ถือไว้ ได้ทั้งหมด.. ..ก็ดี  สิครับ.   จะรู้ ต้นทุนของ กองทุน ว่าถือหุ้น ราคาเท่าไร. จากคุณ : นาย หุ้น n-park (prince-npark) เขียนเมื่อ : วันรัฐธรรมนูญ 54 12:47:16

ความคิดเห็นที่ 70 ^^ชอบตรง 69 นี้ละพี่ งัยพี่บอกผมบ้างนะของพวก POP นะ จากคุณ : แล้วแต่ดวง เขียนเมื่อ : 11 ธ.ค. 54 18:59:38

ความคิดเห็นที่ 71 เป็นอย่างไรบ้างแล้วครับ ? จากคุณ : มิ่งกลิ้ง เขียนเมื่อ : 13 ธ.ค. 54 13:47:07

ความคิดเห็นที่ 72 ผมไม่กล้านำ link กระทู้นี้ไป share และคุยต่อที่อื่นอีก, เพราะ อาจจะผิด พรบ. คอมพ์ ได้ (อาจเข้าข่ายการเผยแพร่วิธีการเจาะระบบความปลอดภัยของผู้อื่น). จากคุณ : อานนท์ ศรีเจริญชัย เขียนเมื่อ : 27 ธ.ค. 54 20:04:15