検索条件
お知らせ
現在サイトのリニューアル作業中のため、全体的にページの表示が乱れています。
前のページ
1
2
3
4
5
6
次のページ
HTTPヘッダを持たないHTTPリクエストはあり得るのか？というのを検証しているときに気づいた話。
RFC 7230ではHostヘッダを持たないHTTPリクエストは禁止されており、これを受けたサーバーは400応答を返すことを必須としている。
RFC 7230:Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing のHost より
A client MUST send a Host header field in an HTTP/1.1 request even if
A server MUST respond with a 400 (Bad Request) status code to any
なお、Node.jsのHTTPサーバー機能ではHostヘッダーのない要求を受け入れることができる。
http.createServer([options][, requestListener]) を見ると、以下のようにrequireHostHeader: falseを渡すことで実現可能だ。規定値はtrueであるため、基本的にはHostヘッダーなしの要求は400応答が返される。
import http from 'node:http';
http
.createServer({requireHostHeader: false}, (req, res) => {
console.log(req.headers);
res.statusCode = 200;
res.end();
})
.listen(3000);
nginxにおいてもHostヘッダーなしの要求は以下の応答が返されたため同様と思われる。
<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/1.26.0</center>
</body>
</html>
但し、nginxにおいてHostなしの要求を許容する方法は見つからなかった。Server names によるとserver_name "";とすることで出来そうに見えたが、これは機能させることができず、400応答が返された。
Galaxy S22 Ultra Android 14
Android端末のストレージにエクスポートしたCA証明書を持ってくる
設定＞セキュリティ＞その他のセキュリティ設定＞ストレージからインストール＞CA証明書＞このままインストール
内部ストレージからエクスポートしたCA証明書を選択
Ubuntu 22.04.3 LTS
$CER_FILE="エクスポートしたCA証明書"
sudo openssl x509 -inform der -outform pem -in $CER_FILE -out PEM.crt
sudo cp PEM.crt /usr/local/share/ca-certificates
sudo update-ca-certificates
Env
Ver
Windows 11 Pro
22621.3155
ユーザー証明書の管理を開く
信頼されたルート証明機関＞証明書
mkcertで始まる証明書を探す
右クリック＞すべてのタスク＞エクスポート
DER encoded binary X.509 (.CER)
適当なファイル名を付けてエクスポート
ここ最近なりすましメールが目立つのでなりすましメール防御対策を取りましょうという話。
ここ数日の間にイラストレーターのIxy先生やMastodonインスタンス管理人のにょき氏といった一定の知名度を持つ人物を中心になりすましメールの被害にあっているようだ。
ここまで目立つのは余り見聞きしなかったので恐らくここ昨今のGMailとかの騒動を見たところで、なりすましメールを作れることに気づいた人物が愉快犯的に行為をしているのだろう。
個人レベルでできる対策としてはDNSレコードやメールサーバーの設定にSPF, DKIM, DMARCを設定することだ。これらの内容についてはGoogleによるDMARC を使用してなりすましと迷惑メールを防止する が詳しい。
さくらのレンタルサーバーを利用している場合は以下が参考になる。
さくらのレンタルサーバーを利用して外部DNSを利用している場合は、私が以前書いたValue-DomainのドメインをさくらのレンタルサーバーのメールでSPF, DKIM, DMARC対応させる が参考になるだろう。
SPD, DKIM, DMARCの三点を設定することで相手のメールサーバーがこれらに対応している場合になりすましメールを迷惑メールとして分類したり、メールの受信を拒否できるとされているため、設定することでなりすましメールを防御できる可能性が高まる。
メール送信に使っていないドメインに関しても以下のようなDMARCを設定しておくことで、悪意のある第三者によるなりすましを防げるだろう。
txt _dmarc v=DMARC1; p=reject; aspf=r; adkim=r
またメールサーバーを運用されている各位におかれては、SPD, DKIM, DMARCの三点を識別し、適切に受信メールをフィルタリングできる仕組みを導入して頂けると犯罪予告や迷惑メールによる被害を減らせる可能性があるので、是非とも導入を検討いただきたい。
前職で古いWebシステムのマイグレーションしてた時に思ったのだが、SameSite CookieがあればCSRF Tokenは最早いらないのではないか？というのに気が付いたので調べてみた話。
結論として言うとEdgeではPOSTリクエストでCookieが飛ぶ事はないので、CSRF Tokenを考慮する必要はなさそうに思える。
理由としてはCookieでSameSite=strictを指定している場合、クロスドメインでのCookie送信がブロックされる という話が事実であればCSRF Tokenは不要であるはずだからだ。
これによって悪意のあるサイトからAjaxやリダイレクト、フォームなどを使った攻撃をした場合にサーバーにCookieが送信されなくなる筈なので、理論上は問題なくなる。
以下では実際にCookieが送信されるかどうかの動きを見てみた。確認環境はMicrosoft Edge 121.0.2277.83。方式のリンクはシーケンス図になっている。
シーケンス図に書いてあるSameSite={var}の{var}にはstrict、laxが入る。確認内容としてはシーケンスの一番最後のHTTPリクエストでCookieが送信されているかどうかを見ている。noneは面倒なので見ていない。
SameSite=strictだと外部サイトから開いたときにCookieが送信されないため、Google検索などから流入された時のログイン状態に不都合が出ると思われるので、その様なケースではSameSite=laxが無難だろう。
SameSite=laxの場合、GETリクエストではCookieが送信されるため、CSRF攻撃を受ける可能性があるが、GETで更新系処理をしない限り基本は問題にならないと思われる。
前のページ
1
2
3
4
5
6
次のページ
