Blog AWS Indonesia

Melindungi Data Autentik dari Bot Scraper dengan Manipulasi Respons Berlapis di AWS WAF

Vertikal industri seperti layanan keuangan dan ritel sangat membutuhkan kontrol terhadap bot untuk mencegah scraping yang merugikan daya saing dan kepercayaan pelanggan. Dengan mengontrol aktivitas bot, mereka dapat melindungi strategi harga, menjaga loyalitas pelanggan, dan mengoptimalkan sumber daya komputasi.  

AWS WAF melindungi aplikasi web dengan mengevaluasi dan melabeli request bot, memverifikasi keabsahannya melalui token fingerprint, serta menganalisis pola untuk mendeteksi anomali, sehingga dapat membedakan bot terverifikasi (search engine crawler) dari yang tidak (scraper). Mitigasinya mencakup pembatasan rate, Challenge, CAPTCHA, pemblokiran, custom HTTP response, serta deteksi berbasis machine learning untuk serangan terdistribusi—memastikan perlindungan menyeluruh bagi keamanan dan kinerja aplikasi web. 

Rancangan Solusi 

Kebutuhan Sistem Feeder Data Palsu 

Aktor di balik pengembangan bot (scraper)  secara berkelanjutan mengadaptasi vektor serangannya untuk mengelak dari kontrol yang diterapkan—memodifikasi pola serangan, mengemulasi perilaku manusia melalui browser automation, dan mendistribusikan permintaan ke sejumlah alamat IP residensial untuk menyamarkan diri sebagai trafik yang sah. Ancaman yang terus berkembang menuntut pemantauan dan penyesuaian berkala pada aturan AWS WAF, yang menambah beban operasional dalam menjaga efektivitas mitigasi. 

Sistem Feeder Data Palsu merupakan pendekatan deception-based untuk memproteksi data original sekaligus mereduksi overhead analisis log. Mekanisme decoy ini merespons bot dengan payload data fiktif yang tampak autentik, memberikan keberhasilan semu pada bot—yang memperlambat perkembangan vektor penyerangan. Blog ini menguraikan implementasi Feeder Data Palsu berbasis AWS WAF Bot Control untuk mendeteksi scraping melalui browser automation framework. 

Arsitektur Solusi Sebelum Feeder Data Palsu 

Berikut adalah aplikasi web three-tier yang berjalan di AWS Lambda, dan menerima request melalui Application Load Balancer (ALB) dan Amazon CloudFront.  

Gambar 1: Contoh Arsitektur web three-tier menggunakan Application Load Balancer, Lambda dan DynamoDB

 Target Arsitektur Solusi setelah Feeder Data Palsu 

Pada CloudFront, kita menggunakan rule yang dikelola AWS WAF Bot Control untuk mendeteksi dan melakukan routing berdasarkan custom header. Dengan solusi ini, maka bot scraper tidak akan mendapatkan data original namun menerima data finansial yang sudah dimodifikasi oleh aplikasi Feeder Data Palsu. Dalam pendekatan Feeder Data Palsu, kita memanfaatkan AWS WAF Bot Control hanya sebagai lapisan deteksi. Sistem ini memberi label dan menambahkan header HTTP khusus pada HTTP request yang dicurigai sebagai bot. Berdasarkan header HTTP khusus dari AWS WAF Bot Control, ALB mengarahkan permintaan ke backend terpisah yang merespons dengan informasi palsu. Untuk meminimalkan usaha implementasi, aplikasi Feeder dapat dibuat sebagai replika aplikasi asli yang dimodifikasi untuk memberikan respons palsu.

Untuk kesederhanaan tutorial ini, kami menggunakan label aws:managed:aws:bot-control:bot:category:http_library dari AWS WAF Bot Control Common Rule “CategoryHttpLibrary” sebagai kondisi untuk menambahkan header HTTP pada permintaan yang dicurigai sebagai bot. Label ini menandakan bahwa request tidak datang dari browser melainkan dari tool seperti curl. Anda dapat menggabungkan berbagai label dari label AWS WAF Bot Control lainnya untuk membuat aturan yang sesuai dengan aktivitas bot yang diamati. 

 

Gambar 2: Arsitektur web three-tier setelah implementasi solusi feeder data palsu

Langkah Membangun Sistem 

Langkah 1 : Deploy aplikasi original dan aplikasi “Feeder Data Palsu”

Pada AWS console, masuk pada console Lambda dan buat function Lambda baru. Beri nama lambda-ori-app. Pilih runtime Python 3.12. Biarkan opsi lain nya default. 

Gambar 3: Membuat Lambda Function sebagain Web App Layer

Pada bagian code, masukkan code berikut pada code editor. Pilih deploy. 

def lambda_handler(event, context):
    # in the real application, get the catalog from DB or API calls
    products = [
        {"id": 1, "name": "Table", "price": 199.99},
        {"id": 2, "name": "Chair", "price": 89.99}
    ]

    # HTML template as a string
    HTML_TEMPLATE = """
        <!DOCTYPE html>
        <html lang="en">
        <head>
            <meta charset="UTF-8">
            <meta name="viewport" content="width=device-width, initial-scale=1.0">
            <title>Product List</title>
            <style>
                body {{ font-family: Arial, sans-serif; max-width: 800px; margin: 0 auto; padding: 20px; }}
                h1 {{ color: #333; }}
                ul {{ list-style-type: none; padding: 0; }}
                li {{ margin-bottom: 10px; }}
            </style>
        </head>
        <body>
            <h1>Product List</h1>
            <ul id="product-list">
                {product_list}
            </ul>
        </body>
        </html>
    """
    # price response
    product_list = "\n".join([f"<li>{product['name']} - ${product['price']}</li>" for product in products])
    html = HTML_TEMPLATE.format(product_list=product_list)
    return {
        'statusCode': 200,
        'headers': {'Content-Type': 'text/html'},
        'body': html
    } 

Buat Lambda function kedua. Kali ini beri nama lambda-feederDataPalsu-app. Pilih runtime Python 3.12. Biarkan opsi lainnya default. Perhatikan pada lambda-feederDataPalsu-app ini kita memberikan harga yang berbeda. 

Kali ini pada bagian code editor, masukkan code yang sama dengan di atas namun memiliki respon harga yang berbeda seperti di bawah. Klik deploy. 

def lambda_handler(event, context):
    # perbedaan harga pada feeder data palsu
    products = [
        {"id": 1, "name": "Table", "price": 599.99},
        {"id": 2, "name": "Chair", "price": 189.99}
    ]

    # HTML template as a string
    HTML_TEMPLATE = """
        <!DOCTYPE html>
        <html lang="en">
        <head>
            <meta charset="UTF-8">
            <meta name="viewport" content="width=device-width, initial-scale=1.0">
            <title>Product List</title>
            <style>
                body {{ font-family: Arial, sans-serif; max-width: 800px; margin: 0 auto; padding: 20px; }}
                h1 {{ color: #333; }}
                ul {{ list-style-type: none; padding: 0; }}
                li {{ margin-bottom: 10px; }}
            </style>
        </head>
        <body>
            <h1>Product List</h1>
            <ul id="product-list">
                {product_list}
            </ul>
        </body>
        </html>
    """
    # price response
    product_list = "\n".join([f"<li>{product['name']} - ${product['price']}</li>" for product in products])
    html = HTML_TEMPLATE.format(product_list=product_list)
    return {
        'statusCode': 200,
        'headers': {'Content-Type': 'text/html'},
        'body': html
    } 

Masuk ke consoled “EC2—Load Balancing—Create new target group”. Pilih opsi Lambda function, berikan nama lambda-ori-tg. Pilih check box health check, biarkan default route path /.  


Gambar 4: Langkah pertama untuk mengkonfigurasi Lambda function sebagai target dari ALB

Pada register target, pilih select Lambda function. Ketik dan cari nama lambda blog-original-app. Biarkan opsi lain default dan pilih create target group. 

Gambar 5: Langkah kedua untuk mengkonfigurasi Lambda function sebagai target dari ALB  

Buat target group kedua sesuai step di atas, namakan lambda-feederDataPalsu-tg . Kali ini pilih select lambda function. ketik dan cari nama lambda lambda-feederDataPalsu-app. Biarkan opsi lain default dan klik create target group. 

Selanjutnya kita akan membuat Application Load Balancer untuk kedua aplikasi di atas. Sebelum mengikuti langkah berikut ini, pastikan kita sudah memiliki VPC dengan dengan setidaknya satu public subnet di setiap Availability Zone. Untuk informasi lebih lanjut kunjungi halaman ini. 

  1. Masuk ke AWS EC2 Console, pilih Load Balancer pada sub-kategori Load Balancing di menu navigasi sebelah kiri. Pilih tombol Create load balancer. 
  2. Pada halaman Compare and select load balancer type pilih tombol Create pada Application Load Balancer sebagai Load Balancer type.  
  3. Pada halaman Create Application Load Balancer bagian Basic configuration, lakukan hal berikut ini: 
    1. Untuk Load balancer name masukan  product-price-alb. 
    2. Untuk scheme, pilih Internet-facing. 
    3. Untuk Load balancer IP address type, pilih IPv4. 
  4. Pada halaman Create Application Load Balancer bagian Network mapping 
    1. Untuk VPC, gunakan VPC yang memiliki public subnet sebagai VPC yang digunakan.  
    2. Untuk Mappings, pilih setidaknya 2 availability zone (AZ) dan public subnet yang sesuai di AZ tersebut pada bagian Availability Zones. 
  5. Pada halaman Create Application Load Balancer bagian Security groups, kita bisa memilih security group yang sudah kita miliki sebelumnya atau membuat security group baru dengan memilih Create a new security group. Security group yang digunakan pada tutorial ini harus memperbolehkan akses ke HTTP port 80 dari internet. Silahkan merujuk pada halaman ini untuk rekomendasi security group yang sesuai dengan Internet-facing Load Balancer. 
  6. Pada halaman Create Application Load Balancer bagian Listeners and routing, masukkan Protocol HTTP, Port 80. Pada Default action, ketik dan pilih lambda-ori-tg. Ini akan menjadi rule default kita. 

Turun hingga bagian bawah halaman, akhiri dengan pilih create load balancer. Kini kita bisa melihat hasil ALB yang sudah dibuat. Pada tab Details kita dapat menemukan domain name ALB kita pada bagian DNS name. Copy nilai DNS name dan paste pada web browser untuk melihat Aplikasi original. 

Gambar 6: Contoh Aplikasi Web yang akan kita lindungi dari Bot

Langkah 2 : Edit Load balancer dengan custom-header routing 

Tambahkan custom header rule pada ALB yang sudah kita buat. Pilih load balancer yang sudah kita buat di langkah sebelumnya, dan lakukan hal berikut ini: 

  1. Pada bagian Listeners and rules. Pilih rule HTTP:80 yang sudah kita buat pada Langkah 1, Manage rules dan Edit rules.  
  2. Pada halaman detail rule HTTP:80, pada bagian Rules, pilih Add rule. 
  3. Pada halaman Step 1 Add rule, Name and tags, masukan nama yang diinginkan. 
  4. Pada halaman Step 2 Define rule conditions, pilih Add condition.  
    1. Untuk Rule conditions type, gunakan HTTP Header.  
    2. Untuk HTTP header name, masukkan value custom header yang akan dipakai, x-amzn-waf-header-bot. dengan HTTP header value is bot.  
    3. Pilih Confirm dan Next. 
    4. Gambar 7: Konfigurasi ALB untuk HTTP header yang mengindikasikan akses dari bot
  5.  Pada Step 3 Define rule actions,  
    1. Untuk Routing actions, pilih Forward to target groups.  
    2. Pada bagian Forward to target group, pilih target group lambda-Feeder Data Palsu-tg yang sudah kita buat untuk aplikasi Feeder Data Palsu. Lanjutkan dengan Next.
    3. Gambar 8: Konfigurasi ALB rule action untuk meneruskan  akses dari bot ke aplikasi feeder data palsu
  6.  Pada Step 4 Set rule priority Edit, naikkan priority rule header-bot menjadi nomor 1. Lanjutkan dengan Next. 
  7. Pada Step 5 Review and create, lanjutkan dengan Next dan selesaikan dengan Create rule. Maka kita akan melihat 2 rule aktif pada listener port 80 seperti di bawah. 
  8. Gambar 9: AWS WAF bot label yang akan ditandai sebagai akses dari bot

Tes http request dengan dan tanpa custom header untuk melihat apakah forwarding rule bekerja dengan baik. 

curl product-price-alb-261837xxx.ap-southeast-1.elb.amazonaws.com 

        <body>
            <h1>Product List</h1>
            <ul id="product-list">
                <li>Table - $199.99</li>
                <li>Chair - $89.99</li>
            </ul>
        </body> 

curl --header "x-amzn-AWS WAF-header-bot:bot" product-price-alb-26183xxx.ap-southeast-1.elb.amazonaws.com 

        <body>
            <h1>Product List</h1>
            <ul id="product-list">
                <li>Table - $599.99</li>
                <li>Chair - $189.99</li>
            </ul>
        </body> 

Langkah 3 : Implementasi Cloudfront dengan ALB Origin 

Tahapan selanjutnya adalah membuat Cloudfront distribution baru dengan ALB sebagai origin: 

  1. Masuk ke AWS CloudFront Console dan pilih Create distribution. 
  2. Pada halaman Create distribution, pilih domain dari ALB yang kita buat pada langkah 1 sebagain Origin domain. 
  3. Gunakan HTTP only sebagai Protocol. 
  4. Masih pada halaman Create distribution, pada bagian Web Application Firewal (WAF), pilih Enable security protections.
  5. Biarkan konfigurasi yang lain pada nilai default dan pilih Create distribution. 

Langkah 4 : Implement AWS WAF bot control dengan custom-header insertion di Cloudfront distribution 

Dikarenakan pada Langkah 3.4, kita memilih Enable security protection, maka CloudFront akan secara otomatis membuat AWS WAF WebACL dan mengasosiasikannya dengan CloudFront distribution yang kita buat. Langkah selanjutnya adalah membuat Bot Control Managed Rule Groups pada WebACL ini. Ikuti langkah berikut ini: 

  1. Masuk ke AWS WAF Console dan pilih menu WebACL. 
  2. Kita akan menemukan WebACL yang dibuat secara otomatis oleh CloudFront. WebACL tersebut diawali dengan awal CreatedByCloudFront. Pilih WebACL tersebut. 
  3. Setelah kita masuk pada halaman detail dr WebACL yang dibuat oleh CloudFront, pilih tab Rules, Add rules, dan pilih Add managed rule groups. 
  4. Pada halaman Add managed rule groups, aktifkan Bot Control dengan memilih tombol Add to web ACL dan pilih Edit. 
  5. Pada halaman selanjutnya, pada Bot Control inspection level, pilih Common. Untuk tutorial ini kita menggunakan Common protection level, meskipun demikian, teknik yang dibahas pada blog ini dapat digunakan pada Targeted protection level. 
  6. Untuk Scope of inspection, pilih “Inspect all web requests”.  
  7. Pada Common Section, pada item CategoryHttpLibrary dan CategoryScrapingFramework, pilih Override to count.  Action count tidak akan yang memblok request, dan aksi ini juga akan menambahkan label awswaf:managed:aws:bot-control:bot:category:http_library pada request traffic yang cocok dengan rule CategoryHttpLibrary. Label tersebut akan tersedia dalam rule selanjutnya.  
  8. Akhiri dengan memilih Add rules.  
  9. Pada halaman set rule priority, lanjutkan dengan memilih Save.

Setelah Rule Bot Control berhasil ditambahkan, kita lanjutkan dengan membuat custom rule yang berfungsi untuk menambahkan HTTP header x-amzn-waf-header-bot dengan value bot. ALB yang berada setelah CloudFront, akan menggunakan HTTP header ini untuk meneruskan request ke target group lambda-feederDataPalsu-tg.  Ikuti langkah berikut ini: 

  1. Masuk ke AWS WAF Console dan pilih menu WebACL. Pilih WebACL yang dibuat secara otomatis oleh CloudFront (nama WebACL tersebut memiliki awalan CreatedByCloudFront). 
  2. Setelah kita masuk pada halaman detail dr WebACL yang dibuat oleh CloudFront, pilih tab Rules, Add rules, dan pilih Add my own rules and rule groups. 
  3. Pada halaman Rule builder, pada Name, masukkan nama custom rule name seperti “header-bot-rule”. Pilih Regular rule pada Type. 
  4. Biarkan bagian If a request menggunakan konfigurasi default matches the statement. 
  5. Pada bagian Statement, Inspect, pilih Has a label. Pada Match scope, pilih Label, dan masukan awswaf:managed:aws:bot-control:bot:category:http_library sebagai nilai dari Match key. 
  6. Gambar 10: AWS WAF bot label yang akan ditandai sebagai akses dari bot
  7. Untuk bagian Then, pilih action Count. Buka bagian Custom request – optional, tambahkan new custom header. Masukkan key dengan nilai header-bot and value dengan bot. 
  8. Lanjutkan dengan Save rule. 
  9. Gambar 11: Konfigurasi AWS WAF untuk menambahkan header-bot

Ikuti seluruh poin dari Langkah 4 untuk membuat custom rule kedua dengan nama header-bot-rule-httpLib. Hanya saja, pada poin 14 dari Langkah 4, kita menggunakan awswaf:managed:aws:bot-control:bot:category:scraping_framework sebagai nilai dari Match key. Selain dari pada poin 14 tersebut, gunakan konfigurasi yang sama sesuai panduan pada Langkah 4. 

Di akhir proses maka kita sudah memiliki 2 custom rule yang melakukan penambahan HTTP custom header jika rule Bot Control mendeteksi request yang datang dari HTTP Library atau dari scraping framework. HTTP header ini akan dipakai oleh ALB untuk melakukan routing ke aplikasi Feeder Data Palsu. Logic penambahan custom header di rule httpLib dan scraping menggunakan label yg dihasilkan oleh Rule Bot Control. 

Gambar 12: Penempatan rule AWS WAF untuk meneruskan bot HTTP header

Anda dapat membaca lebih lanjut untuk fitur menambahkan custom header dengan AWS WAF pada dokumentasi  Inserting custom request headers for non-blocking actions. 

Hasil 

Pengujian trafik asli/organik melalui penggunaan Web browser ke domain Cloudfront  https://dXXXXXXXXXXXXw.cloudfront.net/  akan menampilkan harga dengan diskon yaitu Table – $ 199.99 dan chair $ 89.99. Kemudian bandingkan dengan simulasi pengiriman trafik bot melalui perintah  curl  https://dXXXXXXXXXXXXw.cloudfront.net/  yang merupakan http library. Eksekusi perintah curl terhadap URL CloudFront akan menghasilkan harga tanpa diskon yaitu Table – $ 599.99 dan Chair – $ 189.99. 

Pada console AWS WAF, pilih webACL yang kita buat, di bagian traffic overview di bawah, kita dapat melihat bahwa hasil curl terdeteksi sebagai sinyal bot scraping. 

Gambar 13: AWS WAF metric berdasarkan label dari requests

Arsitektur Solusi yang dibahas pada blog ini memungkinkan kita untuk memberikan data palsu kepada bot yang melakukan otomasi menggunakan library HTTP. Hal ini berhasil dilakukan dengan menggunakan deteksi AWS WAF Bot Control, penyisipan custom header dan forwarding ke target group dari Aplikasi Feeder Data Palsu. Penyisipan header khusus ini tidak terlihat oleh requestor web (bot) karena deteksi dan penyisipan dilakukan di belakang CloudFront oleh AWS WAF Bot Control. Rule ini bisa menjadi fondasi sebelum menggunakan berbagai kombinasi rule dan label lain dari AWS Bot Control yang memungkinkan kita mendeteksi bot yang lebih canggih. 

Pertimbangan lainnya 

Contoh di atas menunjukkan penggunaan deteksi bot AWS WAF untuk trafik bot yang menggunakan HttpLibrary dan ScrapingFramework lainnya. Pertimbangkan untuk menerapkan label deteksi lain yang disediakan oleh fitur AWS WAF Bot Control yang bergantung pada integrasi aplikasi menggunakan AWS WAF Bot Control SDK, seperti: 

  • Volumetrik/Tingkat Permintaan: Memantau volume dan komposisi trafik untuk mengidentifikasi anomali yang dapat menunjukkan aktivitas bot dari sumber klien tertentu. 
  • Tanpa Token: Memblokir permintaan yang tidak menyertakan token AWS WAF yang valid untuk mencegah akses yang tidak sah. 
  • Klien IP dari Penyedia Cloud: Memblokir request dari alamat IP yang terkait dengan penyedia cloud untuk mencegah kemungkinan trafik pengguna akhir yang non-legitimate dengan menggunakan grup aturan reputasi IP. 
  • Kegagalan CAPTCHA Berulang: Memantau kegagalan berulang pada tantangan CAPTCHA untuk mengidentifikasi dan memblokir trafik bot. 

Sebagai arsitektur alternatif, AWS WAF Bot Control juga terintegrasi dengan Amazon API Gateway, AWS Application Load Balancer, dan CloudFront—dengan penyisipan dan pengalihan custom header tersedia pada lapisan API Gateway serta ALB. Penting untuk memastikan sistem Feeder Data Palsu menyajikan nilai yang berbeda dari data asli, namun tetap cukup masuk akal agar bot penyerang tidak menyadari bahwa ia sedang disesatkan. Terapkan juga  logging pada Feeder Data Palsu untuk mengevaluasi aktivitas bot yang masuk; jika tidak ada log trafik yang diterima, kemungkinan bot mendeteksi mekanisme ini, sehingga label deteksi dan redirect perlu disesuaikan. 

Membersihkan Sumber Daya (Cleanup) 

Guna mencegah timbulnya biaya yang tidak diperlukan, disarankan untuk menghapus seluruh sumber daya yang dibuat selama tutorial ini, meliputi CloudFront distribution beserta WebACL AWS WAF yang terasosiasi, Application Load Balancer dan kedua target group, serta kedua fungsi Lambda yang telah dideploy. 

Kesimpulan 

Dalam blog ini, kita telah menunjukkan cara membangun sistem Feeder Data Palsu untuk mengalihkan serangan bot dengan menggunakan AWS WAF Bot Control dan penggunaan custom-header. Solusi ini akan mengurangi kecepatan evolusi bot jahat yang akan mengurangi biaya operasional dari kompleksitas rule pada AWS WAF. 

Bila Anda ingin mempelajari konsep yang dibahas pada artikel ini secara menyeluruh, Anda bisa menuju halaman panduan web AWS WAF, AWS WAF Bot Control, Cloudfront, Elastic Load Balancer. Anda juga bisa mencoba materi skill builder gratis tentang WAF untuk memulai eksplorasi.  

Pugar Jayanegara

Pugar Jayanegara

Pugar adalah seorang Senior Solution Architect di AWS dengan keahlian khusus dalam container, di mana ia membantu pelanggan untuk mentransformasi bisnis mereka. Sebelum bergabung dengan AWS, ia bekerja di berbagai perusahaan teknologi dan cloud utama dengan peran senior solution architect dalam integrasi sistem dan pengembangan software. Ia antusias dalam mengeksplorasi teknologi baru, membangun solusi kreatif & efektif untuk pelanggan dan mitra.

Attha Surya Dharma

Attha Surya Dharma

Attha adalah seorang Senior Technical Account Manager di AWS Indonesia. Dia membantu pelanggan AWS menjalankan operasional AWS sesuai dengan berbagai standar praktik terbaik operasi cloud. Sebelum bergabung dengan AWS, Attha bekerja di perusahaan teknologi multinasional lainnya di bidang konsultasi dan layanan profesional. Attha memiliki antusiasme tinggi dalam setiap perannya sebagai konsultan untuk berbagai pelanggan di berbagai vertikal bisnis, yang mendorongnya untuk terus berkembang secara profesional

Elkana Pariwono

Elkana Pariwono

Elkana adalah seorang Technical Account Manager di AWS Indonesia dengan keahlian khusus dalam Edge Technology. Dia membantu pelanggan AWS menjalankan operasional AWS sesuai dengan berbagai standar praktik terbaik operasi cloud. Sebelum bergabung dengan AWS, Elkana bekerja di berbagai perusahaan teknologi multinasional lainnya di bidang cloud dan layanan profesional. Elkana memiliki antusiasme tinggi dalam setiap perannya sebagai konsultan untuk berbagai pelanggan di berbagai vertikal bisnis, yang mendorongnya untuk terus berkembang secara profesional.