Apakah titik dua `:` aman untuk penggunaan ramah-URL?


109

Kami merancang sistem URL yang akan menentukan bagian aplikasi sebagai kata-kata yang dipisahkan oleh garis miring. Secara khusus, ini ada di GWT, jadi bagian yang relevan dari URL akan ada di hash (yang akan ditafsirkan oleh lapisan pengontrol di sisi klien):

http://site/gwturl#section1/section2

Beberapa bagian mungkin memerlukan atribut tambahan, yang ingin kami tentukan dengan a :, agar bagian URL tidak ambigu. Kode akan terpecah pertama /, kemudian :, seperti ini:

http://site/gwturl#user:45/comments

Tentu saja, kami melakukan ini untuk keramahan url, jadi kami ingin memastikan bahwa tidak satu pun dari karakter ini yang memiliki arti khusus akan dienkode-url oleh browser, atau sistem lain, dan berakhir dengan url seperti ini:

http://site/gwturl#user%3A45/comments <--- BAD

Apakah menggunakan titik dua dengan cara ini aman (maksud saya tidak akan secara otomatis dikodekan) untuk browser, sistem bookmark, bahkan Javascript atau kode Java?


Mungkin ide yang baik untuk menentukan (lebih jelas) bahwa Anda menggunakan URL hanya di sisi klien? Karena banyak jawaban (seperti yang saya lakukan) tampaknya berasumsi bahwa Anda akan mengirim URL ke server menggunakan HTTP.
Veger

Diedit untuk menambahkan klarifikasi bahwa penggunaan fragmen terjadi di sisi klien.
Nicole

Saya penasaran: setelah 10 bulan, apakah skema url ini berhasil untuk Anda? Saya sedang mempertimbangkan untuk menggunakan skema yang sama.
Jonathan Swinney

1
@Jonathan Swinney, Sayangnya saya telah pindah dari proyek ini (dan perusahaan), meskipun jawaban di sini memuaskan saya bahwa itulah cara yang harus ditempuh. Jika saya akan memulai proyek baru, saya akan menggunakan skema ini, tetapi saya juga akan menggunakan skema ini #!untuk menunjukkan bahwa halaman tersebut berstatus stateful - lihat googlewebmastercentral.blogspot.com/2009/10/… (Proposal ini telah ditaati oleh pengguna AJAX berat seperti Facebook)
Nicole

Saya baru tahu bahwa WhatsApp akan memotong URL di titik dua pertama, jadi misalnya itu membuat URL peta google tidak berguna. Jadi ya, penting untuk menghindarinya.
Petruza

Jawaban:


84

Saya baru-baru ini menulis encoder URL, jadi ini cukup segar dalam pikiran saya.

http://site/gwturl#user:45/comments

Semua karakter di bagian fragmen ( user:45/comments) legal untuk RFC 3986 URI .

Bagian-bagian yang relevan dari ABNF :

fragment      = *( pchar / "/" / "?" )
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

Terlepas dari batasan ini, bagian fragmen tidak memiliki struktur yang ditentukan selain yang diberikan aplikasi Anda. Skemanya, http, hanya mengatakan bahwa Anda tidak mengirim bagian ini ke server.


EDIT:

D'oh!

Terlepas dari pernyataan saya tentang spesifikasi URI, irreputable memberikan jawaban yang benar ketika dia menunjukkan bahwa spesifikasi HTML 4 membatasi nama / pengenal elemen .

Perhatikan bahwa aturan pengenal berubah di HTML 5 . Pembatasan URI akan tetap berlaku (pada saat penulisan, ada beberapa masalah yang belum terselesaikan seputar penggunaan URI HTML 5).


Saya pikir Anda sedang melakukan sesuatu, dapatkah Anda menjelaskannya lebih jauh? Tidak mengirimkan ini ke server tidak menjadi masalah, karena kami menggunakan GWT. Saya hanya tidak yakin saya jelas tentang sintaks yang ditentukan oleh bagian yang Anda kutip.
Nicole

Tapi :merupakan gen-delim, bukan sub-delim.
bobince

1
Titik koma legal untuk pchar, jadi apakah itu dalam sub-delim atau gen-delim tidak menjadi masalah
Veger

@bobince - :masuk pchar, yang masuk fragment, jadi :diperbolehkan. @Renesis - Wikipedia memiliki artikel di ABNF en.wikipedia.org/wiki/ABNF Anda pada dasarnya melihat daftar karakter yang diizinkan, di mana /artinya OR . Saya belum melakukan pemrograman GWT, jadi saya tidak tahu bagaimana ia menggunakan bagian fragmen URI.
McDowell

Satu pertanyaan terakhir - apakah Anda memiliki wawasan tentang aplikasi dunia nyata dari spesifikasi ini? Apakah ini berarti browser harus / akan mengabaikan (melewatkan encoding) :di dalam fragmen?
Nicole

59

Selain analisis McDowell tentang standar URI, ingat juga bahwa fragmen harus berupa nama jangkar HTML yang valid. Menurut http://www.w3.org/TR/html4/types.html#type-name

Token ID dan NAMA harus dimulai dengan huruf ([A-Za-z]) dan dapat diikuti dengan sejumlah huruf, angka ([0-9]), tanda hubung ("-"), setrip bawah ("_") , titik dua (":"), dan titik (".").

Jadi Anda beruntung. ":" diizinkan secara eksplisit. Dan tidak ada yang harus "%" - menghindarinya, tidak hanya karena "%" adalah char ilegal di sana, tetapi juga karena fragmen harus cocok dengan nama anchor char-by-char, oleh karena itu tidak ada agen yang mencoba merusaknya dengan cara apa pun.

Bagaimanapun Anda harus mengujinya. Standar web tidak diikuti dengan ketat, terkadang standarnya saling bertentangan. Misalnya HTTP / 1.1 RFC 2616 tidak mengizinkan string kueri di URL permintaan, sementara HTML membuatnya saat mengirimkan formulir dengan metode GET. Apa pun yang diterapkan di dunia nyata akan menang pada akhirnya.


58

MediaWiki dan mesin wiki lainnya menggunakan titik dua di URL mereka untuk menunjukkan ruang nama, tanpa masalah besar.

mis. http://en.wikipedia.org/wiki/Template:Welcome


31
Jawaban paling relevan. Kita semua tahu bahwa apa yang ada di spesifikasi tidak ada hubungannya dengan kenyataan dalam pengembangan web. Anda tidak akan mendapatkan jaminan "keamanan" yang jauh lebih baik daripada "salah satu dari 10 situs web teratas di dunia melakukannya".
Steven Collins

1
@StevenCollins Tidak lebih relevan daripada jawaban yang diberikan 3 tahun sebelumnya yang menyatakan hal yang persis sama :)
Martin James

7

Saya tidak akan mengandalkannya. Ini kemungkinan akan mendapatkan url yang dikodekan %3Aoleh banyak agen pengguna.


1
@arbales: Ya. Beberapa agen pengguna yang kurang patuh akan membiarkan url yang tidak patuh tanpa hiasan.
Asaf

4

Dari URLEncoderjavadoc:

Untuk informasi lebih lanjut tentang pengkodean formulir HTML, lihat spesifikasi HTML .

Saat mengenkode String, aturan berikut berlaku:

  • Karakter alfanumerik "a" sampai "z", "A" sampai "Z" dan "0" sampai "9" tetap sama.
  • Karakter khusus ".", "-", "*", dan "_" tetap sama.
  • Karakter spasi "" diubah menjadi tanda plus "+".
  • Semua karakter lain tidak aman dan pertama-tama diubah menjadi satu atau lebih byte menggunakan beberapa skema encoding. Kemudian setiap byte diwakili oleh string 3 karakter "% xy", di mana xy adalah representasi heksadesimal dua digit dari byte. Skema encoding yang direkomendasikan untuk digunakan adalah UTF-8. Namun, untuk alasan kompatibilitas, jika encoding tidak ditentukan, maka encoding default platform akan digunakan.

Artinya, :tidak aman.


3

Saya tidak melihat Firefox atau IE8 mengkodekan beberapa URL Wikipedia yang menyertakan karakter tersebut.


1
Opera juga menyimpan titik koma, tetapi mengandalkan perilaku seperti itu bukanlah hal yang baik untuk dilakukan
Veger

1
Renesis berbicara tentang fragmen URL dan bukan jalur URL.
Gumbo

Wikipedia adalah salah satu pemikiran saya saat menulis pertanyaan ini. Apakah penggunaan titik dua secara teknis tidak valid / tidak aman? Saya biasanya melihat (dan) di URL Wikipedia dikodekan, tetapi tidak pernah titik dua, yang membuat saya agak bingung.
Nicole

3
Mesin Wayback memiliki: di banyak tautannya
barrowc

2

Titik dua digunakan sebagai pemisah antara nama pengguna dan kata sandi jika protokol memerlukan otentikasi.


0

Usus besar tidak aman. Lihat disini


Halaman itu tidak memotivasi mengapa mereka tidak aman. RFC2396 yang direferensikan tidak mengatakan bahwa ia juga harus di-escape. Selain itu, skrip konverter yang disediakan tidak menyandikannya (di Chrome 9).
Adam Lindberg

Adam, kamu salah. Ini secara langsung menyatakan apa dan mengapa.
ktamlyn

-5

Ini bukan karakter yang aman dan digunakan untuk membedakan port mana yang Anda sambungkan ketika berada tepat setelah nama domain Anda

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.