As I wrote in my previous article, static sites are more beneficial for corporate and LP sites that have no user-activated functions. However, for other ordinary web systems, there must be dynamic processing in the backend. In this article, we will talk about security.

Back-end access control and security measures

What I want to think about this time is something like the following. This can happen not only with static sites, but also with ordinary SSR sites (systems built with .Net, Rails, or laravel). By the way, client means browser or application.

In other words, it’s very scary to be in a situation where bad people can knock around APIs from non-specific clients. There are some countermeasures, but there are a lot of sites, especially static sites, that have poor countermeasures.

Is this about CORS, CSRF, etc., NO!

First of all, proper user authentication and not governing the allowed domains of CORS, sending CSRF tokens, etc. should be a matter of course.If you Google CORS, CSRF, XSS, etc., you will find countermeasures for both SSR and SPA sites, so if you are not sure, check them out.

So, what I want to write about this time is not about CSRF or CORS! Regardless of whether you have authentication or not, whether you check the access origin or set cookies to HTTPOnly, if you can easily hit the API with a non-browser request such as cURL, then there is some risk of fraud. Even if you have user authentication, you can make a direct API call if someone gets your authentication token and uses it. Also, CORS and cookie restrictions are only for browsers.
At the same time, we want to allow communication from smartphone apps and desktop apps only for requests from within those apps. (Obfuscation required)

Example of a government bulky waste reception center

If you live in Japan, you have probably used the following website at least once. This is the website of the government’s Bulky Waste Reception Center. This site is a good example.

I found out that the system itself is the same in many municipalities (I’ve seen it in about four municipalities), but the domain name and web server are different for each. Also, the design of the site is a little different in each municipality.

The flow of this government’s bulky waste reception center is as follows.

1. Enter your email address on this site and submit.
2. Open the link you received in the email.
3. After selecting the type of bulky waste, enter your name and address.
4. Submit the application and purchase a bulky waste ticket at a convenience store.

Notice that there is no user authentication, and you can enter your email address at will. Moreover, there is no need to enter your name or address at this point. In other words, anyone can send to any center in any city or ward with any e-mail address.
If a hijacked stepping-stone server could mechanically access the POST address, it would be possible to send tens of thousands of bulk garbage collection e-mails to a specific e-mail address. How much bulky waste do you want to collect? But for the recipient, it’s not so bad.
Of course, if you start a browser with a robot and operate it as described in this article, you can do anything you want, but there are many restrictions on the server to do this, and it is not that easy (restrictions on the privileges of the stepping stone server, etc.). So the question is whether it is possible to POST with a command such as cURL.

Bulk Garbage Reception Center, you’re so easy!

As it turns out, it was possible to send continuously with cURL. In other words, it’s a government system. What kind of a system is this for a Japanese local government? I’m not going to go into the details of the request just to be safe, but I will briefly introduce the security measures of this system.

Issue session ID on top page?

It seems that the SessionID is issued and set in the cookie on the screen before the email address submission screen. But you can easily check it with your browser’s inspector. If you don’t have this SessionID, you will get an error on the email address submission screen.

Hexadecimal timestamps in query parameters?

The URL of the email address submission screen has a mysterious query parameter (te-uniquekey), but I immediately knew what it represented as soon as I saw it.

When I converted this hexadecimal number to decimal, it seemed to represent the millisecond of the UNIX timestamp perfectly. This may be used to control the time, but since it is a query parameter, we can create and send as many as we want. It’s a timestamp, but the name “uniquekey” (unique key) seems silly.

The hidden tag has a fixed token!?

And this is important, but I can see what looks like a token in the hidden tag of the email address submission screen.

This is a complete guess, but I think it is a cipher value or hash value of SessionID and secret key (or UNIX timestamp as mentioned above). So the value of this token remains the same even if you reload or switch screens again. In other words, it is easy to extract and use this value as well.

You can request collection from overseas IPs.

This is not really related to this article, but this web system can be accessed from foreign IPs. Since the government doesn’t go to foreign countries to collect bulky garbage, wouldn’t it be better to restrict foreign IPs?

Japanese traveling in Hawaii：「Oh! I’ll have to take out the old rack at home for bulky waste. push push」

No, do it when you get back to Japan. They don’t sell bulky trash tickets in Hawaii. It’s hard to say, but from a security standpoint, I think it would be better if this Japanese local government’s bulky trash site only allowed domestic IPs.

Continuous calls can be made with cURL

The investigation so far shows that it is possible to make a call. In fact, it was easy to create a request and succeeded. And I actually received an email from the bulky waste center. By the way, I left an interval of about 10 minutes for the test so as not to cause any trouble.
The problems with this system don’t end there. What a surprise! Once a token is used, it can be used over and over again! And the time limit seems to be almost non-existent. I have already confirmed that the same request will still succeed the next day. No, what’s up with the aforementioned timestamp query parameter.
If bad people who can somehow cover up the source of the request send a large number of requests to the POST destination of this bulky trash center, a number of emails will be sent to a specific email address. For example, they might be able to pull off a prank by doing so, popping the target mail server.

To make people give up unauthorized operations.To make people give up unauthorized operations.To make people give up unauthorized operations.

The system of the bulky waste center I saw this time is a national system, but it’s just like this. What I’m trying to say is that it’s better to take anti-fraud measures for sending data to the server. As mentioned above, you should take measures against CORS, CSRF, XSS, and the following measures as well.

• Issue a one-time token.
• Shorten the session validity period.
• Restricting access from overseas IPs
• Obfuscation of application source, JS, Wasm, etc.

Even I can understand the fraudulent measures of the system of this bulky waste center after just a few minutes of browsing, and I know that it is easy to break through. They may think that since it is just a matter of sending an e-mail, there is no problem even if it is manipulated illegally. They may also be limiting the number of POSTs in a very short sequence of time. But at least the token should be one-time. A token that still works the next day is a problem.

Ideally, it would be possible to block or respond in error to HTTP requests from places other than the client, such as a specific site or a specific application. However, it is not possible to prevent such malicious activities at 100%. Bad hackers will somehow be able to figure out the security measures and how to break through them if they take their time. However, if there are too many layers of security measures in place, the hackers will find it too costly to break through and give up. In particular, WebAPIs that support SPA sites, especially APIs that can be called without user authentication, must be thoroughly protected against unauthorized access.