protocol - Dave's Blog


JavaScript Microsoft Store app StartPage

2017 Jun 22, 8:58

JavaScript Microsoft Store apps have some details related to activation that are specific to JavaScript Store apps and that are poorly documented which I’ll describe here.

StartPage syntax

The StartPage attributes in the AppxManifest.xml (Package/Applications/Application/@StartPage, Package/Applications/Extensions/Extension/@StartPage) define the HTML page entry point for that kind of activation. That is, Application/@StartPage defines the entry point for tile activation, Extension[@Category="windows.protocol"]/@StartPage defines the entry point for URI handling activation, etc. There are two kinds of supported values in StartPage attributes: relative Windows file paths and absolute URIs. If the attribute doesn’t parse as an absolute URI then it is instead interpreted as relative Windows file path.

This implies a few things that I’ll declare explicitly here. Windows file paths, unlike URIs, don’t have a query or fragment, so if you are using a relative Windows file path for your StartPage attribute you cannot include anything like ‘?param=value’ at the end. Absolute URIs use percent-encoding for reserved characters like ‘%’ and ‘#’. If you have a ‘#’ in your HTML filename then you need to percent-encode that ‘#’ for a URI and not for a relative Windows file path.

If you specify a relative Windows file path, it is turned into an ms-appx URI by changing all backslashes to forward slashes, percent-encoding reserved characters, and combining the result with a base URI of ms-appx:///. Accordingly the relative Windows file paths are relative to the root of your package. If you are using a relative Windows file path as your StartPage and need to switch to using a URI so you can include a query or fragment, you can follow the same steps above.

StartPage validity

The validity of the StartPage is not determined before activation. If the StartPage is a relative Windows file path for a file that doesn’t exist, or an absolute URI that is not in the Application Content URI Rules, or something that doesn’t parse as a Windows file path or URI, or otherwise an absolute URI that fails to resolve (404, bad hostname, etc etc) then the JavaScript app will navigate to the app’s navigation error page (perhaps more on that in a future blog post). Just to call it out explicitly because I have personally accidentally done this: StartPage URIs are not automatically included in the Application Content URI Rules and if you forget to include your StartPage in your ACUR you will always fail to navigate to that StartPage.

StartPage navigation

When your app is activated for a particular activation kind, the StartPage value from the entry in your app’s manifest that corresponds to that activation kind is used as the navigation target. If the app is not already running, the app is activated, navigated to that StartPage value and then the Windows.UI.WebUI.WebUIApplication activated event is fired (more details on the order of various events in a moment). If, however, your app is already running and an activation occurs, we navigate or don’t navigate to the corresponding StartPage depending on the current page of the app. Take the app’s current top level document’s URI and if after removing the fragment it already matches the StartPage value then we won’t navigate and will jump straight to firing the WebUIApplication activated event.

Since navigating the top-level document means destroying the current JavaScript engine instance and losing all your state, this behavior might be a problem for you. If so, you can use the MSApp.pageHandlesAllApplicationActivations(true) API to always skip navigating to the StartPage and instead always jump straight to firing the WebUIApplication activated event. This does require of course that all of your pages all handle all activation kinds about which any part of your app cares.


Tweet from Pwn All The Things

2016 Sep 6, 10:47
Oh My God. This report is such a troll. Hackers cleverly hid their searching of network shares using "SMB protocol"

location.hash and are bad and they should feel bad

2014 May 22, 9:25
The DOM location interface exposes the HTML document's URI parsed into its properties. However, it is ancient and has problems that bug me but otherwise rarely show up in the real world. Complaining about mostly theoretical issues is why blogging exists, so here goes:
  • The location object's search, hash, and protocol properties are all misnomers that lead to confusion about the correct terms:
    • The 'search' property returns the URI's query property. The query property isn't limited to containing search terms.
    • The 'hash' property returns the URI's fragment property. This one is just named after its delimiter. It should be called the fragment.
    • The 'protocol' property returns the URI's scheme property. A URI's scheme isn't necessarily a protocol. The http URI scheme of course uses the HTTP protocol, but the https URI scheme is the HTTP protocol over SSL/TLS - there is no HTTPS protocol. Similarly for something like mailto - there is no mailto wire protocol.
  • The 'hash' and 'search' location properties both return null in the case that their corresponding URI property doesn't exist or if its the empty string. A URI with no query property and a URI with an empty string query property that are otherwise the same, are not equal URIs and are allowed by HTTP to return different content. Similarly for the fragment. Unless the specific URI scheme defines otherwise, an empty query or hash isn't the same as no query or hash.
But like complaining about the number of minutes in an hour none of this can ever change without huge compat issues on the web. Accordingly I can only give my thanks to Anne van Kesteren and the awesome work on the URL standard moving towards a more sane (but still working practically within the constraints of compat) location object and URI parsing in the browser.

Stripe CTF - Level 5

2012 Sep 11, 5:00

Level 5 of the Stripe CTF revolved around a design issue in an OpenID like protocol.


    def authenticated?(body)
body =~ /[^\w]AUTHENTICATED[^\w]*$/


if authenticated?(body)
session[:auth_user] = username
session[:auth_host] = host
return "Remote server responded with: #{body}." \
" Authenticated as #{username}@#{host}!"


This level is an implementation of a federated identity protocol. You give it an endpoint URI and a username and password, it posts the username and password to the endpoint URI, and if the response is 'AUTHENTICATED' then access is allowed. It is easy to be authenticated on a server you control, but this level requires you to authenticate from the server running the level. This level only talks to stripe CTF servers so the first step is to upload a document to the level 2 server containing the text 'AUTHENTICATED' and we can now authenticate on a level 2 server. Notice that the level 5 server will dump out the content of the endpoint URI and that the regexp it uses to detect the text 'AUTHENTICATED' can match on that dump. Accordingly I uploaded an authenticated file to
Using that as my endpoint URI means authenticating as level 2. I can then choose the following endpoint URI to authenticate as level 5.
Navigating to that URI results in the level 5 server telling me I'm authenticated as level 2 and lists the text of the level 2 file 'AUTHENTICATED'. Feeding this back into the level 5 server as my endpoint URI means level 5 seeing 'AUTHENTICATED' coming back from a level 5 URI.


I didn't see any particular code review red flags, really the issue here is that the regular expression testing for 'AUTHENTICATED' is too permisive and the protocol itself doesn't do enough. The protocol requires only a set piece of common literal text to be returned which makes it easy for a server to accidentally fall into authenticating. Having the endpoint URI have to return variable text based on the input would make it much harder for a server to accidentally authenticate.

PermalinkCommentsinternet openid security stripe-ctf technical web

Stripe Web Security CTF Summary

2012 Aug 30, 5:00

I was the 546th person to complete Stripe's web security CTF and again had a ton of fun applying my theoretical knowledge of web security issues to the (semi-)real world. As I went through the levels I thought about what red flags jumped out at me (or should have) that I could apply to future code reviews:

Level Issue Code Review Red Flags
0 Simple SQL injection No encoding when constructing SQL command strings. Constructing SQL command strings instead of SQL API
1 extract($_GET); No input validation.
2 Arbitrary PHP execution No input validation. Allow file uploads. File permissions modification.
3 Advanced SQL injection Constructing SQL command strings instead of SQL API.
4 HTML injection, XSS and CSRF No encoding when constructing HTML. No CSRF counter measures. Passwords stored in plain text. Password displayed on site.
5 Pingback server doesn't need to opt-in n/a - By design protocol issue.
6 Script injection and XSS No encoding while constructing script. Deny list (of dangerous characters). Passwords stored in plain text. Password displayed on site.
7 Length extension attack Custom crypto code. Constructing SQL command string instead of SQL API.
8 Side channel attack Password handling code. Timing attack mitigation too clever.

More about each level in the future.

PermalinkCommentscode-review coding csrf html internet programming script security sql stripe technical web xss

The "acct" URI Scheme

2012 Jun 30, 3:09

During formalization of the WebFinger protocol [I-D.jones-appsawg-webfinger], much discussion occurred regarding the appropriate URI scheme to include when specifying a user’s account as a web link [RFC5988].

acctURI      =  “acct:” userpart “@” domainpart

PermalinkCommentstechnical uri uri-scheme acct ietf

Application Protocols in Windows 8

2012 Jun 12, 4:09
In Windows 8 you can still register a desktop application to handle a particular URI scheme, but now you can also register a Metro Win8 application to handle a particular URI scheme. No more manually modifying the registry - now there's pretty UI in VS to handle this.
PermalinkCommentsapplication-uri programming technical uri windows windows8

Prime HTTP Status Codes

2012 Feb 22, 4:00
These are the prime HTTP status codes:
PermalinkCommentshttp prime technical useless

"Deprecating Use of the "X-" Prefix in Application Protocols" - Peter Saint-Andre, D. Crocker, Mark Nottingham

2011 Oct 19, 2:07
Don't prefix your proprietary URI schemes with "x-". Your company name or label reversed domain name is acceptable though.

Use of the "X-" Prefix in Application Protocols

2011 Jul 1, 10:12" Historically, protocol designers and implementers distinguished
between "standard" and "non-standard" parameters by prefixing the
latter with the string "X-". On balance, this "X-" convention has
more costs than benefits, although it can be appropriate in certain
circumstances."PermalinkCommentsprefix technical standrad rfc uri url x-


2011 Jun 10, 8:14Protolol aggregates protocol related tweet jokes: "The problem with TCP jokes is that people keep retelling them slower until you get them." - eigenrickPermalinkCommentshumor technical protocol tcp tcp-ip

A Taxonomy on Private Use Fields in Protocols

2011 May 22, 10:36Notes and suggestions for private use fields in protocols and formats.PermalinkCommentsietf rfc protocol technical private-use

SRU: Search/Retrieval via URL -- SRU, CQL and ZeeRex (Standards, Library of Congress)

2011 Apr 18, 4:27"SRU is a standard XML-focused search protocol for Internet search queries, utilizing CQL (Contextual Query Language), a standard syntax for representing queries."PermalinkCommentsstandards search library metadata xml uri technical library-of-congress

draft-hammer-hostmeta-14 - Web Host Metadata

2011 Apr 17, 12:51"Web-based protocols often require the discovery of host policy or metadata, where "host" is not a single resource but the entity controlling the collection of resources identified by Uniform Resource Identifiers (URI) with a common URI host [RFC3986]."PermalinkCommentshost rfc reference metadata technical

draft-ietf-oauth-v2 - The OAuth 2.0 Protocol Framework

2010 Dec 15, 10:02The OAuth 2 spec still in progress.PermalinkCommentsspecification reference ietf spec oauth technical

lcamtuf's blog: HTTP cookies, or how not to design protocols

2010 Nov 8, 3:34On crappy aspects of HTTP cookie design.PermalinkCommentshttp web browser history technical cookie header networking protocol security programming via:mattb

RFC 5987 - Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters

2010 Aug 13, 11:47Other characters sets for HTTP headers: "By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO-8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231."PermalinkCommentsrfc language localization charset http technical reference http-header

Salmon Protocol: Protocol Summary

2010 Jun 20, 2:05A more friendly summary of the Salmon Protocol -- the distributed commenting procotol. After telling Sarah I was reading about salmon, we watched the Salmon Dance video again.PermalinkCommentstechnical salmon protocol comment atom rss social reference

Draft: The Salmon Protocol

2010 Jun 20, 1:18Protocol for doing distributed commenting and implemented by Google Buzz! "This document defines a lightweight, robust, and secure protocol for sending unsolicited notifications — especially comments and responses on syndicated feed content — to specified endpoints; along with rules to enable resulting content to itself be syndicated robustly and securely."PermalinkCommentscomment blog atom rss google buzz salmon reference specification protocol syndication technical

RFC 5870 - A Uniform Resource Identifier for Geographic Locations ('geo' URI)

2010 Jun 9, 3:31"A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way."PermalinkCommentstechnical geo uri url ietf rfc standard
Older Entries Creative Commons License Some rights reserved.