Hacking di Serial Phantom/Ghost/유령 (bagian 3)

Mulai dari episode 7, jumlah hacking dan tool hacking yang muncul semakin sedikit, jadi untuk bagian 3 ini episode yang dibahas lebih banyak: dari 7 sampai 14. Ada laporan teknis yang muncul sekilas, dan dibuat cukup meyakinkan dengan screenshot program di dalamnya.

Ada juga adegan akuisisi data dari ponsel.

Sementara itu ketika mengakses komputer orang lain (secara tidak legal) dan butuh akses browser history, Yoo Kang-mi memakai BrowserHistorySpy.

Ada sedikit omongan teknis tentang ARP attack, tapi tidak detail diceritakan.

Dan software forensik sebelumnya masih muncul lagi

Dalam kecelakaan mobil, ditemukan USB flash drive dengan firmware ECU. Entah kenapa di Flash drive itu ada software WinHex. Tapi bisa saya pahami ini dibuat agar ceritanya berjalan dengan cepat. Tokoh utama membuka file itu dan menemukan kata-kata “ECU”.

Saya tidak tahu jenis mobil dsb, tapi mobil jenis tertentu memang bisa ditamper kontrolnya, bahkan dari jauh (jika mobil itu punya konektivitas wireless. Di Blackhat 2016 bahkan ada sesi Car Hacking Hands On.

Sayangnya waktu melakukan analisis firmware ECU, software yang dipakai masih ollydbg juga dan yang ditampilkan adalah program PE Windows. Ini juga bisa saya mengerti: di tahun tersebut hanya IDA Pro yang cukup bagus untuk melakukan reverse engineering firmware non x86, dan mereka tidak ingin membayar mahal hanya demi film tersebut.

Setelah itu ada aksi remote akses menggunakan software radmin.

Dan ada adegan keylogging juga. Tokoh utamanya melakukan keylogging sambil memonitor hasilnya realtime.

Ketika melakukan analisis cepat terhadap software beta, mereka membuka log file untuk melihat kelakuan program. Ini sangat masuk akal.

Seingat saya sisa film ini tidak banyak lagi hackingnya, jadi kemungkinan bagian berikutnya akan jadi bagian terakhir. Meskipun episode-episode ini kurang banyak hackingnya, tapi mereka tetap berusaha memasukkan program yang akurat jika memungkinkan. Ceritanya sampai titik ini juga masih cukup baik (penuh misteri dan kerja detektif).

Hacking di Serial Phantom/Ghost/유령 (bagian 2)

Meneruskan posting sebelumnya, ini episode 4 sampai 6. Pertama ada program tak bernama yang bisa digunakan untuk SQL injection dsb, fiturnya mirip dengan sqlmap tapi ada GUI-nya. Program ini ternyata namanya HDSI (saya nemu ini karena menemukan tulisan berbahasa korea yang membahas film ini).

EnCase juga muncul lagi beberapa kali di film ini.

Program open source wireshark yang dipakai untuk memonitor traffic jaringan juga muncul di film ini.

Beberapa serial TV tidak pernah menampilkan IP address beneran, tapi serial ini sering sekali memberikan alamat IP.

Walau yang di atas itu bukan alamat IP hong kong

Ada juga tampilan log firewall Cisco

Dan berikutnya adalah bagian yang paling menarik menurut saya. Ada malware yang memiliki tanggal aktivasi. Reverse engineering dilakukan dengan ollydbg. Program dihentikan di instruksi:

CMP DWORD PTR DS:[EDX], 0x4FD68680

Instruksi ini sangat masuk akal (instruksi perbandingan, bukan instruksi yang lain), lalu tokohnya menggunakan konverter time stamp untuk mengubah 0x4FD68680 menjadi tanggal saat ini.

Saya bisa mengkonfirmasi dengan python bahwa angka timestamp yang ditampilkan adalah benar.

Dibahas juga mengenai stuxnet, malware yang sempat merepotkan Iran dalam riset nuklirnya.

Tapi indicator of compromise (IOC)-nya tidak dibuat realistis. Dengan hanya dengan melihat beberapa proses yang normal bisa disimpulkan bahwa ini stuxnet. Padahal mereka bisa membuat seolah-olah ada nama yang lebih masuk akal untuk indikator stuxnet.

Program DDOS Master yang mereka pakai sepertinya custom atau mengubah program yang sudah ada. Tampilannya sangat masuk akal, nama-nama serangan DOS-nya juga masuk akal.

Tampilannya agak mirip dengan botmaster console

Sekarang ke bagian nostalgia masa lalu. Pertama tentang Y2K dan virus CIH yang terkenal di jaman itu.

Ditampilkan debugger mode DOS. Ini bukan virus CIH yang didebug, tapi sekedar program “Hello World” yang memakai interrupt 21 dengan fungsi AH=9. Yang menariknya, dokumen di belakang debugger itu merupakan source code virus CIH yang beneran.

Debugging program hello world, dengan source code CIH di latar belakang
Potongan Virus CIH yang sebenarnya

Untuk virus Melissa, mereka tidak memperlihatkan isi macronya. Hanya adegan mengirimkan dokumen berisi virus ke seseorang.

Demikian pembahasan kali ini. Akan saya teruskan pembahasannya di posting berikutnya. Tapi setelah 6 episode ini jumlah “hacking”-nya semakin menurun dan ceritanya yang semakin banyak.

Hacking di Serial Phantom/Ghost/유령 (bagian 1)

Sebenarnya film drama Phantom ini sudah cukup lama (tahun 2012) dan sudah pernah saya tonton beberapa tahun sebelumnya, tapi karena sekarang Risna lagi rajin nonton drama korea kami jadi nonton lagi film ini. Saya akan membahas mengenai berbagai tool yang dipakai di serial ini. Beberapa konsep yang rumit yang tidak cukup ditulis di posting ini akan saya posting di posting yang lain.

Saya berusaha untuk tidak memberikan spoiler di posting ini, tapi ya mungkin saja tetap ada sedikit. Sebagai catatan: ini sekedar film fiksi, jadi banyak juga hal-hal yang kurang realististis supaya filmya lebih seru. Sama seperti adegan baku tembak atau kejar-kejaran mobil di berbagai film lain yang juga sering tidak masuk akal. Tapi meski demikian film ini cukup realistis dari segi software yang dipakai.

Posting bagian pertama ini hanya membahas Episode 1 sampai 3. Di tiap episode pemakaian komputer/toolnya bervariasi, jadi dalam tiap bagian posting ini saya tidak akan selalu membahas tiap 3 episode, bisa lebih bisa kurang.

Hal pertama yang menarik ketika Kim Woo-hyun mengcompile program custom. Dia secara manual mengetik: gcc -v .. dst. Padahal di situ ada Makefile, harusnya tinggal ketik “make” saja sudah cukup.

Compile program

Sementara itu Park Ki-young memakai metasploit dalam aksinya. Metasploit adalah software standar yang dipakai baik hacker maupun pentester untuk melakukan banyak hal (scanning system, eksploitasi sistem, membuat payload, dsb).

Metasploit

Ketika tim forensik menerima laptop barang bukti mereka tidak langsung mengakses komputernya. Sebelum analisis forensik dilakukan mereka membuat dulu “disk image”. Juga ditunjukkan harddisk laptop bersanding dengan harddisk target.

Cloning/imaging disk

Software yang dipakai adalah Image Master Forensic. Ini software yang benar-benar ada.

Image master forensic

Analisis kemudian dilakukan menggunakan software Encase yang sangat dikenal oleh kalangan Digital Forensik.

Encase

Di episode pertama ada juga beberapa software yang tidak saya kenal, misalnya software untuk mengakses kamera. Ada kemungkinan softwarenya adalah software lokal Korea.

Saya tidak mengenali software ini

Di sana mereka memiliki beberapa software yang lebih umum dibandingkan dengan yang kita pakai sehari-hari. Contohnya format dokumen yang umum bukan DOC tapi HWP (dari software Hangul Office). File dengan ekstensi HWP ini banyak muncul di film ini karena memang terkenal di kalangan pemerintah Korea Selatan.

Saya tidak bisa berbahasa Korea, jadi tidak tahu apakah terjemahannya 100% benar atau tidak, tapi secara umum penjelasanya cukup baik. Misalnya dikatakan bahwa Steganografi digunakan untuk menyembunyikan informasi di file gambar atau musik. Secara teori file apapun bisa, walau di file multimedia (gambar, video, suara) datanya bisa lebih tersembunyi karena ukuran filenya sudah besar.

Sebenarnya file apa saja bisa digunakan untuk steganografi.

Software yang digunakan dalam film ini adalah OpenStego

OpenStego

Beberapa software tampaknya dibuat custom, contohnya ketika Yoo Kang-mi mengedit data pasien, terlihat bahwa ikonnya merupakan ikon standar aplikasi .NET (C#/VB.NET) yang dibuat dengan visual studio.

Software custom

Bisa dibandingkan Ikon HIS di aplikasi tersebut dengan ikon aplikasi yang belum diganti di Visual Studio.

Ikon standar aplikasi dengan Visual Studio

Bukan cuma program GUI itu saja yang dibuat custom, program command line juga dibuat custom. Program pertama yang saya sebutkan ternyata di dalam cerita itu adalah untuk melakukan tracing. Saya agak tersenyum dia mengcompile pakai parameter -v (verbose) cuma supaya layarnya terlihat lebih penuh.

Ternyata program di screen capture pertama adalah REVERSE TRACER (ini tidak beneran ada)

Sebelum melakukan serangan, dilakukan recon dulu dengan nmap (GUI interface untuk nmap)

Scanning dengan GUI Nmap

Outputnya juga diperlihatkan

Ini targetnya server Linux. Nggak tau kenapa ke server itu, karena targetnya adalah user yang memakai Windows.

Yang jadi target port 9929, ini nggak masuk akal (port ini tidak standar digunakan).

bagian ini juga kurang masuk akal

Selain masalah tool, film ini juga kadang menjelaskan konsep tertentu. Misalnya di episode 3 ini dijelaskan tentang konsep Phishing attack. Dijelaskan juga contoh-contoh kenapa orang membuka attachment yang tidak dikenal di email.

Contoh email phishing

Sekian pembahasan kali ini. Saya tidak akan membahas dalam mengenai ceritanya: dari segi cerita, kadang ceritanya agak terlalu ribet/kurang masuk akal, tapi lumayan seru juga. Bagi saya ini cukup menarik karena mereka punya flashback ke tahun 1999/2000 di masa virus CIH, Melissa dan masalah Y2K. Nostalgia kembali ke masa kuliah saya. Bagian mengenai flashback masa lalu ini akan saya bahas di bagian berikutnya.

Mencari bug

Ada yang bertanya ke saya: bagaimana sih caranya mencari bug di aplikasi? Karena jawabannya tidak bisa ditulis singkat di chat, di tulisan kali ini saya akan berusaha menjawab pertanyaan itu.

Apa itu bug?

Kalau Anda disuruh mencari sebuah benda tapi tidak tahu benda itu seperti apa bentuknya maka Anda tidak akan bisa menemukannya (Contoh: tolong ambil logic analyzer di laci saya). Sama halnya dengan bug: pertama pahami dulu berbagai jenis bug yang ada, baru Anda bisa menemukannya.

Contoh-contoh bug web misalnya: SQL Injection, IDOR, XSS, dan command injection. Contoh bug aplikasi misalnya: buffer overflow. Selain tahu apa itu sebuah bug, kita juga perlu tahu bagaimana cara mengeksploitasinya.

Black box testing

Ini testing yang paling umum. Kita coba-coba berbagai input dengan harapan keluar suatu pesan error yang bisa menunjukkan kesalahan di sebuah program. Contoh kecil: jika ada input petik tunggal (‘) dan programnya menampilkan SQL error, maka kemungkinan ada bug SQL injection.

Tentunya coba-coba ini harus yang masuk akal. Ini biasanya tergantung pada: aplikasinya seperti apa, servernya memakai OS apa. Contoh: berusaha melakukan command injection dengan berbagai command Windows di server Linux maka tidak akan berhasil. Berusaha melakukan angular template injection di aplikasi yang tidak memakai Javascript juga tidak akan berhasil.

Intinya: meskipun ini adalah black box testing, yang sepertinya sekeda menebak-nebak, ada hal-hal masuk akal yang bisa kita coba. Jika kita ingin membeli suatu barang, kita bisa mencoba mengganti nilai pembelian, berusaha membypass proses pembayaran, dsb.

White box testing

Jika kita memiliki akses ke source code, maka kita bisa mencari bug dengan membaca source code aplikasinya. Source ini bisa didapat dari beberapa cara:

  • Aplikasinya memang open source (contoh: berbagai aplikasi web seperti WordPress ada source codenya)
  • Dari hasil dekompilasi (contohnya: berbagai game bisa didekompilasi)
  • Dari bug lain (contoh: jika menemukan bug web untuk membaca sebuah file, maka bisa kita manfaatkan untuk membaca source code aplikasi)

Nah di sini kemampuan membaca source code diperlukan. Dengan adanya source code, kita bisa melihat alur program dan menentukan apakah sebuah input dicek atau tidak, dan apakah inputnya bisa dipakai untuk membypass sesuatu atau mengeksekusi apa yang seharusnya tidak boleh dieksekusi.

Memahami Tool

Untuk melakukan testing, kita perlu paham berbagai tool yang sesuai. Contohnya untuk testing aplikasi web, kita sebaiknya memakai intercepting proxy (seperti Burp atau Zaproxy). Dengan memakai tool tersebut, kita bisa mengganti request dari browser atau dari aplikasi baik desktop maupun mobile yang akan berkomunikasi dengan server di internet.

Untuk testing aplikasi mobile, keahlian mengekstrak package, melakuan dekompilasi diperlukan. Berbagai tools yang spesifik juga bisa dipakai (misalnya XPosed Framework di Android, atau Frida di berbagai OS lain).

Fuzzing

Untuk bug jenis tertentu, kita bisa memakai tools untuk melakukan fuzzing. Intinya adalah mencoba-coba berbagai input secara otomatis. Ini bisa diaplikasikan ke aplikasi web, atau bahkan aplikasi desktop (contohnya ada yang namanya AFL). Penggunaan fuzzer ini relatif mudah, tapi hasilnya tetap harus dipahami oleh orang yang memiliki skill.

Otomasi

Sebagian bug bisa ditemukan dengan menggunakan tool otomatis. Saya tidak akan membahas ini secara dalam. Intinya ada beberapa scanner aplikasi web yang bisa menemukan berbagai bug yang umum. Ada juga source code analyzer yang bisa menemukan berbagai masalah di source code.

Penutup

Mencari bug kadang mudah kadang sulit, tergantung program yang kita cari bugnya. Sebagian orang yang meretas web tidak mencari bug khusus, tapi biasanya yang terjadi seperti ini:

  • ada yang menemukan bug di aplikasi tertentu (contoh: Drupal)
  • ada yang membuat exploit untuk bug tersebut
  • script kiddies menggunakan Google untuk mencari website yang memakai Drupal (dengan dorking, misalnya mencari “Powered By …”
  • script kiddies mencoba exploit drupal pada website yang ditemukan

Selamat mencari bug.

Bug Insecure Direct Object References (IDOR)

Bug Insecure Direct Object References (IDOR) ini merupakan bug yang sangat sederhana, sangat umum dan biasanya sangat berbahaya. Intinya pengguna aplikasi bisa mengubah input sedemikian hingga bisa mengakses objek/data yang bukan miliknya.

Bug paling sederhana adalah jika ada URL seperti ini:

http://example.com/edit.php?produk=1

Jika kita ganti produk menjadi 2 (atau nilai lain) dan keluar detail produk yang seharusnya bukan milik kita, itu namanya IDOR. Sering kali bug IDOR tidak bisa dieksploitasi dengan sederhana seperti itu. Biasanya untuk mengeksploitasi bug semacam ini kita akan memanfaatkan intercepting proxy seperti burp suit atau zaproxy (pernah saya bahas di sini).

Kadang kala ketika berusaha mengedit suatu data, kita tidak bisa memakai IDOR, tapi ketika kita menekan tombol “UPDATE” dan datanya di POST ke server, ternyata kita bisa mengedit id produknya. Jadi dalam kasus ini kita bisa menimpa/update produk lain walaupun tidak bisa melihat hasilnya.

Dalam aplikasi mobile, IDOR ini juga banyak ditemui, tapi secara umum lebih sulit dieksploitasi. Pertama kita perlu mensetup proxy, lalu jika aplikasinya melakukan SSL pinning maka perlu dibypass, dan kadang kala di atas itu masih ada enkripsi custom.

IDOR yang tipenya sangat berbahaya adalah dalam aplikasi yang melibatkan uang. Sering kali saya temu kasus di mana kita bisa mengganti id pengirim transaksi sehingga bisa memindahkan uang dari satu account ke yang lain. Kebanyakan kasus ini terjadi pada aplikasi mobile yang mengakses API dari web dan dienkripsi dengan sangat ribet. Proteksi di sisi client sering kali lebih dipentingkan daripada sisi server.

HTTP Cookie dan Session

Ini hal dasar dalam protokol HTTP yang sangat berguna untuk security. Cookie adalah data kecil yang dikirim oleh server ke browser, dan akan dikirimkan kembali oleh browser ketika mengunjungi website yang sama. Analoginya jika kita pergi ke dokter, kita diberi kartu, dan ketika kembali lagi ke dokter tersebut, kita memberikan lagi kartunya supaya bisa dikenali.

Setelah server memberi “Cookie”, browser akan memberikan lagi “Cookie” ke server di request berikutnya

Dalam kasus sebuah kartu berobat, ada beberapa opsi dalam penyimpanan data. Mungkin kita hanya diberi kartu dengan nomor pasien, lalu seluruh datanya disimpan di dalam komputer klinik atau rumah sakit (atau sekedar di sebuah folder khusus).

Sebuah session dalam aplikasi web adalah sejumlah request dan response yang berhubungan. Misalnya: login, memilih barang, membeli barang,. sampai logout. Sesuai analogi kartu yang hanya berisi ID, cookie juga bisa berisi ssession ID saja, yaitu berupa karakter random yang tidak bisa ditebak (jika bisa ditebak, kita bisa seolah-olah menjadi orang lain)

Session ID saja

Dalam kasus lain, misalnya untuk dokter anak, kita diberi buku kecil, dan data mengenai anak disimpan di buku itu. Contohnya adalah data mengenai perkembangan berat badan anak. Bagusnya dengan buku seperti ini, kita bisa membawanya ke dokter anak manapun. Dalam kasus Cookie: jika data disimpan di client, maka jika sebuah domain memiliki banyak server, maka tidak perlu sinkronisasi data antar server atau memakai database terpusat.

Data cookie di client, dilindungi dengan signature

Ketika sebuah aplikasi web butuh menyimpan data seseorang yang sedang login, maka biasanya yang dipakai adalah Cookie. Cookie ini bisa sekedar berisi informasi session id (dengan seluruh data ada di server), bisa juga berisi datanya langsung. Karena cookie bisa diedit, maka sebuah aplikasi yang aman akan menambahkan digital signature (pernah saya bahas di sini) atau bahkan datanya semuanya dienkrip.

Ada banyak aturan detail mengenai Cookie, yang meliputi:

  • di domain mana cookie berlaku, apakah hanya di domain utama atau sub domain (analoginya: kartu buat dokter kulit di klinik ini apakah berlaku juga buat dokter gigi?). Dan juga apakah hanya untuk path tertentu (misalnya cookie untuk URL /pembelian/ apakah akan dikirimkan untuk /penjualan)
  • kapan masa berlaku cookie?
  • apakah cookie bisa diakses Javascript
  • apakah cookie yang diset dalam mode HTTPS harus dikirim balik ketika memakai mode HTTP?

Berbagai hal detail tersebut bisa jadi masalah security. Beberapa masalah security lain adalah:

  • pencurian cookie (misalnya dengan XSS/Cross Site Scripting)
  • pengeditan cookie atau pembuatan cookie palsu. Ini hanya terjadi kalau cookienya tidak aman (contoh kasus adalah cookie JWT yang menerima alg none)

Detail mengenai pengeditan cookie ini bisa cukup panjang, jadi tidak akan saya tuliskan di sini. Secara umum bug yang berhubungan dengan cookie sangat bergantung pada framework dan bahasa pemrograman yang dipakai.

Demikian penjelasan singkat mengenai cookie. Sebaiknya buatlah web kecil untuk memahami berbagai perilaku cookie ini agar lebih mengerti, baik dari sisi server maupun sisi client. Install juga program untuk mengedit cookie di browser (atau gunakan intercepting proxy) untuk lebih memahami lagi semuanya.

Security untuk pemula: POST dan GET

Kadang saya merasa lucu membaca komentar dari posting saya. Kalau postingnya terlalu kompleks (seperti berbagai hal yang yang saya tuliskan di blog saya yang berbahasa inggris: tinyhack.com), sedikit sekali yang paham jadi kurang ada komentar yang membangun. Sedangkan jika terlalu sederhana, seperti posting sebelumnya, banyak yang “protes”, atau malah nggak percaya.

Beberapa komentar yang muncul misalnya:

  • Masak bank securitynya seperti itu?
  • Itu kan POST, kok diakses pake GET?

Untuk hal pertama: jangan pikir security bank itu sangat ketat. Untuk hal kedua: sepertinya banyak pemula kurang paham mengenai POST dan GET, dan perlu penjelasan lebih lanjut.

Untuk sistem core banking biasanya cukup dijaga ketat, tapi berbagai sistem disekitarnya tidak demikian. Alasannya:

  • Tidak semua modul dikerjakan oleh internal bank, kadang oleh pihak ketiga
  • Tidak semua bank menyewa pentester atau punya ahli security
  • Tidak semua ahli security atau pentester kerjanya bener
  • Kadang sudah ada SOP internal untuk security tapi dibypass karena “harus tayang hari ini”

Bahkan ketika pentesting, sudah beberapa kali saya menemukan bug super parah di beberapa bank seperti:

  • Bisa transfer dari siapa saja ke siapa saja, termasuk keluar bank
  • Root access di server utama
  • Mendapatkan source code ibanking beberapa bank
  • Akses ke firewall utama bank

Karena posisi saya di Thailand, itu semua akses dari eksternal (bukan testing jaringan internal bank). Jadi bug super parah itu bisa diakses dari luar bank.

Nah sekarang ke pelajaran teknisnya: mengenai request POST dan GET. Secara umum kedua request ini ada dengan tujuan berbeda:

  • GET untuk request yang idempoten (artinya boleh diulangi)
  • POST untuk request yang tidak idempoten, dan umumnya ukuran datanya lebih besar

Di dalam program, kita bisa mengakses isi variabel dari POST dan GET secara terpisah. Tapi di berbagai bahasa pemrograman, kita bisa meminta agar mengakses variabel dari POST (jika ada), lalu GET (jika ada), atau bahkan dari cookie jika ada. Catatan: urutannya tidak harus seperti itu, di berbagai bahasa bisa dikonfigurasi

Misalnya di PHP: $_POST untuk mengakses post, dan $_GET untuk mengakses get. Dan ada $_REQUEST untuk mengakses GET atau POST atau Cookie.

Jadi jika ada request POST ke URL /data/?a=5 dan di dalam data POST ada a=7, maka $_GET["a"] pasti 5, $_POST["a"] pasti 7, dan $_REQUEST["a"] bisa 5 atau 7 tergantung setting variables_order di PHP. Defaultnya adalah nilai GET tapi jika ada nilai POST yang sama, maka akan diganti dengan nilai dari POST.

Bagaimana dengan bahasa lain? sama saja, tergantung framework yang dipakai. Contoh: di framework Flask untuk python ada requests.args untuk GET, requests.form untuk POST, dan request.values untuk POST atau GET (nilai GET akan dipakai jika ada nilai sama antara POST dan GET).

Lalu apa gunanya tahu ini?

Beberapa pengecekan security hanya di level URL atau GET saja. Jadi kadang jika dicek di URL, dan kita ganti jadi request POST, hasilnya jadi lolos. Kadang saya mengetes apakah method POST (seperti dalam posting sebelumnya) bisa diakses juga via GET. Jika bisa, ini memudahkan testing cepat dengan browser.

Dalam kasus tertentu: satu method memakai spesifik $_GET (yang diperiksa adalah isi variabel $_GET["q"] misalnya), lalu di method lain memakai $_REQUEST["q"]. Jika URL dipanggil dengan GET, maka kedua variabel tersebut sama, tapi jika dipanggil dengan POST dengan variabel "q" maka sesuai default PHP, isi $_GET["q"] menjadi berbeda dengan $_REQUEST["q"].

Untuk lebih jelasnya lihat contoh berikut ini. Bisa dilihat source code programnya, lalu programnya diberi request GET dan POST dengan curl. Bisa terlihat bedanya.

Karena mengubah POST/GET ini adalah hal yang umum, banyak yang membuat skrip untuk ini. Misalnya di skrip zaproxy sudah ada yang membuat untuk mengubah POST menjadi GET

Sesuai judulnya: ini hanya membahas bagian dasar sekali mengenai POST dan GET. Saya belum masuk ke berbagai hal/trik lain yang berhubungan dengan request, misalnya:

  • Memakai method lain (PATCH/PUT, dsb)
  • Mengganti content type ketika melakukan post (misalnya dari JSON ke XML)
  • Melakukan injection di semua header (misalnya user agent)

Berbagai hal tersebut mungkin akan saya bahas di posting lain.