Open-redirect to XSS

Open redirects are generally treated as a low risk issue, due to the limited impact (more convincing phishing). However in certain cases a simple open redirect vulnerability can lead to reflected XSS, which I’ll talk about in this post.

Redirecting in a browser can happen in two ways:

1. The browser gets a 30x HTTP response code (e.g. 302 Found) with the destination of the redirect in the Location header
2. The JavaScript running on a site does the redirect by e.g. window.location.href='https://example.com' or window.location.assign('https://example.com'); or window.location.replace('https://example.com');

If an open redirect vulnerability exist with the second type of redirect, it might be an XSS as well using the javascript: pseudo-protocol. E.g. the following JavaScript code will pop up an alert:

url = "javascript:alert(document.domain)"; // coming from the user in real life
window.location.href= url;

Demo

Cross-app Scripting in Android apps

If an Android app accepts Intents to open a URL in a WebView, then a malicious app installed on the same device might open a javascript:alert(1)-like URL, which will run the provided JavaScript in the context of the victim app’s site (that is currently loaded in the WebView). This vulnerability is called Cross-app Scripting.

Restricting Google App Script permissions

Google Apps Script is a rapid application development platform that makes it fast and easy to create business applications that integrate with Google Workspace. You write code in modern JavaScript and have access to built-in libraries for favorite Google Workspace applications like Gmail, Calendar, Drive, and more.

https://developers.google.com/apps-script/overview

Google Apps Script provide an easy way to automate repetitive tasks in the Google ecosystem (e.g. Drive). It is somewhat similar to macros in Microsoft Office. An App Script will ask for permissions before it can interact with any document of the user, and by default these permissions are unnecessarily wide. This write up is meant to help restricting these permissions.

Using LastPass on login forms with more than 2 inputs

LastPass generally handles common login pages with a username and password well, but it breaks on login forms that have more than those two fields. But there is a solution.

The problem

Here is the site I’ll use as an example: the login page of the SMBC bank: [https://direct.smbc.co.jp/aib/aibgsjsw5001.jsp]

The first line gives 2 options for identifying your user: either specify your bank account number (branch code and account number) or use your contractor number. I’m using the first one, so let’s focus on that. The problem is that the branch code and the account numbers are two separate text boxes, thus when I fill them out and login, then LastPass will only save one of them as username.

Getting a .jp domain

I have a super common family name in Hungary: Szabo. It means tailor, and appr. 2% of Hungarians have this family name (203,126 out of 9,730,000). Thus szabo.hu, szabo.eu, szabo.com, szabo.net, szabo.info, szabo.me, szabo.xyz etc. are mostly taken. However I recently checked and szabo.jp was available! Following a Tokyo Cheapo guide I found Star Domain and bought the domain there for 2560 yen/year. (Star Domain has a referral program, so if you use this link, I might earn a little money.)

I already had hosting elsewhere, so I only needed the domain and Star Domain has a pretty straightforward DNS configurator. I read that only people in Japan can register .jp domains, so I expected some verification, but only my phone number was checked and after I paid for the domain, I could use it immediately.

Most part of the site is text based, so Google Translate makes it possible to use it without knowing too much Japanese.