最近クレジットカードの不正利用についてよく聞くが、個人に取っている対策を書いておく。
これはカード番号が漏洩する恐れがなくとも不正利用のリスクがあるからだ。
例えば何かしらの理由でアカウントが乗っ取られたり、サービス側で不正操作されたときに予期しない課金が行われる可能性はある。正直、個人的にサービス側を全く信用しておらず、オペミスやストライキの一環、悪意のある社員によるいたずらなどで不正請求が起きる可能性も懸念している。
例えばOpenAIやNotionでは一度クレジットカードを登録すると削除できない、こういうサービスは怖い。基本的にカード情報を登録しない方向に倒している。
やむを得ず登録してしまった場合は、そのサービスを使わなくなったらアカウントを削除することにしている。
正直、クレカの紐づけ解除できないサービスは全部滅んで欲しい。
例えばSMBCでは解約したカードであっても有効期限まで使える仕様があるため、番号漏洩やクレジットマスター攻撃などによって被害を受ける可能性がある。そこで取れる対策としてはカードの強制停止だ。これはサポートセンターに連絡することでカードそのものを無効化する方法だ。カード番号が機能しなくなれば不正請求される可能性もなくなる。
因みにこの手続きは正規のものではないため不必要に使うのは控えたほうがいいと思う。
逆に言うと解約したカードでも有効期限までは使えてしまうため、サブカードとして使うなどの使途もあるので、利活用の道があるのなら残しておくのも悪くはない。
WSL上のUbuntuで動作するnginxでHTTPSに対応したサーバーを作る方法。実機でも同様の手順でいける
| Env | Ver |
|---|---|
| nginx | nginx/1.18.0 (Ubuntu) |
| mkcert | v1.4.4 |
| Ubuntu | 20.04.6 LTS |
| Windows 11 | 22621.3880 |
mkcert sandbox.testsandbox.test.pemsandbox.test-key.pem/etc/nginx/conf.d/ssl/に移動する/etc/nginx/conf.d/sandbox.test.confを作成し、以下のような記述をする
server {
listen 443 ssl;
client_max_body_size 100m;
server_name sandbox.test;
ssl_certificate conf.d/ssl/sandbox.test+1.pem;
ssl_certificate_key conf.d/ssl/sandbox.test+1-key.pem;
access_log /var/log/nginx/sandbox.access.log;
error_log /var/log/nginx/sandbox.error.log;
# ファイルホスト用
# location / {
# root /usr/share/nginx/html/sandbox;
# index index.html;
# try_files $uri /index.html =404;
# }
# APサーバーへのリバプロ用
location ~ ^/.*$ {
rewrite ^/.*$ / break;
proxy_set_header X-Request-Path $request_uri;
proxy_set_header X-Host $host;
proxy_pass http://127.0.0.1:9999;
}
# fastcgi用
location ~ \.php$ {
root /usr/share/nginx/html/sandbox;
fastcgi_pass unix:/run/php/php8.0-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
sudo service nginx restartmkcertのRoot CAをエクスポートして他の端末に突っ込めば、他の端末でもpemが流用できる
日頃仕事で開発をしていたり、そこら辺のWebサービスの振る舞いを眺めていると不思議というか、奇妙というか、端的に言うとありえないリクエストを投げているものを見かける。
一例としては次のようなものを見たことがある。
これの問題点はまずクライアントのIPを幾らでも捏造できることだ。
クライアントからバックエンドに投げている値など幾らでも偽装できるため、その中にクライアントのIPアドレスを含めるのは何の価値もない。
他にも第三者のサービスを利用しているので、そこが落ちてたり、仕様変更があったりすると使えなくなる。
具体的にはSSRを利用しているNext.jsのサーバーサイドレンダリング側で、クライアントのIPを取得し、後ろにいるAPサーバーにHTTPで投げるときにREMOTE_ADDRヘッダーに入れて送っていたケースだ。curlで表すと次のような形式だ。
curl -H 'REMOTE_ADDR: <ここにIP>' http://example.com
サーバー側はクライアント側のIPをサーバー側が設定するので、このリクエストには意味がない。トラフィックと実装コードの無駄といえる。
サーバー側が何を基にして設定しているかは実装依存だと思うが、恐らく一般的にはトランスポート層より下ではないだろうか？
いわゆるフロントエンドエンジニアや、プログラミングスクール卒などの意識が低いエンジニアらが書いたコードを見ているとこのようなものが散見される印象だが、もう少しちゃんと考えて実装して欲しいと思う。
なんというか、最低限常識とされている部分は理解しておいてほしいなというのはすごく思う。
動機としてはcurlだと見えない部分があるので、自分でHTTPメッセージを手組みして送ってみたかった。
Node.jsとPHPのサーバーでリクエストが期待通り取得できたので、メッセージの実装としては問題ないと思われる。
以下のコードをNode.js v20.11.1を用いて検証
import http from 'node:http';
http
.createServer((req, res) => {
console.log(req.headers);
req.on('data', (chunk) => {
// body
console.log(Buffer.from(chunk).toString());
});
res.statusCode = 200;
res.end();
})
.listen(9999);
echo -e 'GET / HTTP/1.1\r\nHost: localhost:9999\r\n\r\n' | nc localhost 9999
echo -e 'POST / HTTP/1.1\r\nHost: localhost:9999\r\nContent-Length: 4\r\n\r\nhoge' | nc localhost 9999
実際にAPサーバーでリクエストの中身をパース出来るかどうかの観点で見た場合にNode.jsよりPHPのが楽なので、PHPで作ってみた結果、軽くハマったので残しておく。
以下のコードを用いてPHP 8.0.29で検証サーバーを作る場合に、php -S 0.0.0.0:9999としてサーバーを起動すると、Content-Typeヘッダがない場合に正常な動作をしなかった。
<?php
var_dump($_SERVER);
var_dump($_REQUEST);
デバッグ用。生のメッセージが見れるのでダンプしてdiffを取るなどでcurlとecho + ncの差分を見るのに使える。
nc -l 9999
前述のNode.jsサーバーでは400 Bad Request、PHPサーバーでは501 Not Implementedが応答された。
| Env | Ver |
|---|---|
| ルーター | YAMAHA RTX830 |
| ファームウェアRev. | Rev.15.02.26 (Wed Sep 7 12:36:21 2022) |
まず以下のコマンドで対象のIPv6アドレスとポート番号を指定する。IPv6アドレスの取得方法は後述する。
ipv6 filter 静的フィルター番号 pass * 宛先IPv6アドレス フィルタリングするパケットの種類 * 宛先ポート
次に次のコマンドで先ほど設定した静的フィルター番号を指定する。静的フィルター番号はデフォルトで設定されているものがあるはずなので、それに追記する形で行う。
ipv6 lan2 secure filter in 静的フィルター番号...
もし間違えて既存のフィルター番号を消し飛ばした場合はipv6 filterがついてる番号を列挙してやればよい。
IPv6アドレスの取得方法
以下のコマンドを叩くと取れる。もっといい方法があると思うのだがパッと見つからなかった。ifconfigを叩くと無数のアドレスが出てきてどれを選べばいいのかわからないが、軽く見た感じグローバル用とローカル用がごちゃ混ぜになっているようだった。
curl https://ifconfig.me