Czy dwukropek `:` jest bezpieczny przy użyciu przyjaznych adresów URL?

Projektujemy system adresów URL, który będzie określał sekcje aplikacji jako słowa oddzielone ukośnikami. W szczególności jest to w GWT, więc odpowiednie części adresu URL będą w skrócie (który zostanie zinterpretowany przez warstwę kontrolera po stronie klienta):

http://site/gwturl#section1/section2

Niektóre sekcje mogą wymagać dodatkowych atrybutów, które chcielibyśmy określić za pomocą a :, aby części sekcji adresu URL były jednoznaczne. Kod podzieliłby się najpierw /, potem dalej :, w ten sposób:

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

Oczywiście robimy to ze względu na przyjazność dla adresów URL, dlatego chcielibyśmy mieć pewność, że żaden z tych znaków, które będą miały specjalne znaczenie, nie zostanie zakodowany w postaci adresu URL przez przeglądarki ani żaden inny system i nie będzie miał adresu URL takiego jak to:

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

Czy używanie dwukropka w ten sposób jest bezpieczne (co oznacza, że ​​nie zostanie automatycznie zakodowane) dla przeglądarek, systemów zakładek, a nawet kodu Javascript lub Java?

Niedawno napisałem koder URL, więc mam to całkiem świeże w głowie.

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

Wszystkie znaki we fragmencie part ( user:45/comments) są całkowicie legalne dla identyfikatorów URI RFC 3986 .

Odpowiednie części ABNF :

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

Oprócz tych ograniczeń część fragmentowa nie ma zdefiniowanej struktury poza tą, którą daje jej aplikacja. Schemat http mówi tylko, że nie wysyłasz tej części na serwer.

EDYTOWAĆ:

D'oh!

Pomimo moich twierdzeń na temat specyfikacji URI, irreputable dostarcza poprawnej odpowiedzi, gdy zwraca uwagę, że specyfikacja HTML 4 ogranicza nazwy / identyfikatory elementów .

Zwróć uwagę, że zasady dotyczące identyfikatorów zmieniają się w HTML 5 . Ograniczenia dotyczące identyfikatorów URI będą nadal obowiązywać (w chwili pisania tego artykułu istnieją nierozwiązane problemy dotyczące korzystania z URI w HTML 5).

Oprócz analizy McDowella dotyczącej standardu URI pamiętaj również, że fragment musi być prawidłową nazwą kotwicy HTML. Według http://www.w3.org/TR/html4/types.html#type-name

Tokeny ID i NAZWA muszą zaczynać się od litery ([A-Za-z]) i mogą po nich następować dowolne litery, cyfry ([0-9]), łączniki („-”), podkreślenia („_”) , dwukropki („:”) i kropki („.”).

Więc masz szczęście. „:” jest wyraźnie dozwolone. I nikt nie powinien "%" - uciec od tego, nie tylko dlatego, że "%" jest tam niedozwolonym znakiem, ale także dlatego, że fragment musi pasować do nazwy kotwicy znak po znaku, dlatego żaden agent nie powinien próbować ich w żaden sposób manipulować.

Jednak musisz to przetestować. Standardy sieciowe nie są ściśle przestrzegane, czasami standardy są sprzeczne. Na przykład protokół HTTP / 1.1 RFC 2616 nie zezwala na ciąg zapytania w adresie URL żądania, podczas gdy HTML konstruuje go podczas przesyłania formularza metodą GET. Cokolwiek zaimplementowano w prawdziwym świecie, wygrywa pod koniec dnia.

MediaWiki i inne silniki wiki używają dwukropków w swoich adresach URL do oznaczania przestrzeni nazw, bez większych problemów.

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

Nie liczyłbym na to. Prawdopodobnie zostanie zakodowany adres URL, tak jak %3Aprzez wielu klientów użytkownika.

Z URLEncoderjavadoc:

Więcej informacji na temat kodowania formularzy HTML można znaleźć w specyfikacji HTML .

Podczas kodowania ciągu obowiązują następujące zasady:

• Znaki alfanumeryczne od „a” do „z”, od „A” do „Z” i od „0” do „9” pozostają takie same.
• Znaki specjalne „.”, „-”, „*” i „_” pozostają takie same.
• Znak spacji „” jest konwertowany na znak plusa „+”.
• Wszystkie inne znaki są niebezpieczne i są najpierw konwertowane na jeden lub więcej bajtów przy użyciu jakiegoś schematu kodowania. Następnie każdy bajt jest reprezentowany przez 3-znakowy ciąg „% xy”, gdzie xy jest dwucyfrową szesnastkową reprezentacją bajtu. Zalecany schemat kodowania to UTF-8. Jednak ze względu na zgodność, jeśli kodowanie nie zostanie określone, zostanie użyte domyślne kodowanie platformy.

Oznacza to, że :nie jest bezpieczny.

Nie widzę kodującego Firefox lub IE8 niektórych adresów URL Wikipedii, które zawierają ten znak.

Dwukropki służą do podziału między nazwą użytkownika i hasłem, jeśli protokół wymaga uwierzytelnienia.

Okrężnica nie jest bezpieczna. Spójrz tutaj

Nie jest to bezpieczny znak i służy do rozróżnienia portu, z którym się łączysz, gdy znajduje się on bezpośrednio po nazwie domeny