You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 10, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 10, 2023. It is now read-only.
Perhaps any filename extension. Then it could be used to replace web bug type of Canarytokens (so there would be no need to change already planted tokens but just the server).
Yup. Would it be a good idea to make trap URLs return 404 (Not Found) instead of 200 (OK)? I don't know if it's needed at all, but maybe that way we would avoid unintentionally fuzzing JPG parsers and such :)
It would be unexpected if an URL with a .jpg extension returns text/html instead of image/jpeg. Although proper JPEG parsers would recognize this quickly as an invalid image, serving a 404 might have better effects for display on the client side of the trap receiver.
Commit e842d4b is now deployed to the live site. It modifies trap URLs to return status code 404. Moreover we now support trap URL suffixes, which allows appending stuff to the trap URL path as long as the additional part starts with . or /. So if you have a trap URL https://uriteller.io/blah you can also use https://uriteller.io/blah.png or https://uriteller.io/blah/xyzzy.
The suffixes are stored for potential future use. For example https://uriteller.io/blah.png stores the suffix .png. Query string gets counted as a part of the suffix, so https://uriteller.io/blah/xyzzy?hello=world stores /xyzzy?hello=world.
Feel free to try it out! There is currently no particular support for this functionality in the UI side, but it's probably still useful.
Activity
uolevi commentedon Nov 5, 2016
Perhaps any filename extension. Then it could be used to replace web bug type of Canarytokens (so there would be no need to change already planted tokens but just the server).
jviide commentedon Nov 7, 2016
Yup. Would it be a good idea to make trap URLs return 404 (Not Found) instead of 200 (OK)? I don't know if it's needed at all, but maybe that way we would avoid unintentionally fuzzing JPG parsers and such :)
uolevi commentedon Nov 9, 2016
What do you mean by unintentionally fuzzing JPG parsers?
raimue commentedon Nov 9, 2016
It would be unexpected if an URL with a
.jpgextension returnstext/htmlinstead ofimage/jpeg. Although proper JPEG parsers would recognize this quickly as an invalid image, serving a 404 might have better effects for display on the client side of the trap receiver.jviide commentedon Nov 9, 2016
@raimue explained it well. I'm actually not too worried about JPEG, but some less battle-hardened parsers for more exotic formats might have problems.
Other status code choices include 401 (Unauthorized) and 403 (Forbidden).
Returning 451 (Unavailable For Legal Reasons) would be funny though ;)
Support trap URL suffixes & return 404 for traps
jviide commentedon Nov 9, 2016
Commit e842d4b is now deployed to the live site. It modifies trap URLs to return status code 404. Moreover we now support trap URL suffixes, which allows appending stuff to the trap URL path as long as the additional part starts with
.or/. So if you have a trap URLhttps://uriteller.io/blahyou can also usehttps://uriteller.io/blah.pngorhttps://uriteller.io/blah/xyzzy.The suffixes are stored for potential future use. For example
https://uriteller.io/blah.pngstores the suffix.png. Query string gets counted as a part of the suffix, sohttps://uriteller.io/blah/xyzzy?hello=worldstores/xyzzy?hello=world.Feel free to try it out! There is currently no particular support for this functionality in the UI side, but it's probably still useful.