Sheeprograming

原則としては GitLab Documentation にある通りに実行すればとれる。

node でこうやって書いてみた

const request = require('request');

// GITLAB_URL は https://gitlab.example.com 等
// PRIVATE_TOKEN は profile/account から取得できる。これは秘密にするべき情報
const gitlabUrl = GITLAB_URL + '/api/v3/users?private_token=' + PRIVATE_TOKEN;

// SSL 証明書がオレオレな場合に付与
// process.env['NODE_TLS_REJECT_UNAUTHORIZED'] = '0';

function getGitlabUsers(url, callback, opt_num, opt_array) {
	var num = opt_num || 0;
	var list = opt_array || [];
	request(url + '&page=' + num, function(e, res, body){
		var result = JSON.parse(body);
		if(result.length) {
			list = list.concat(result);
			getGitlabUsers(url, callback, num + 1, list);
		} else {
			callback(list);
		}
	});
}

getGitlabUsers(gitlabUrl, function(userList) {
	console.log(userList.length, '人のユーザが登録されているぴょん');
});

Promise とか使えばもう少しきれいに書けると思う。node を使わなくても上記 gitlabUrl への curl を打ち続ければユーザリストは取れる。ただし、一度に20人しか取れず、21人目以降は page 引数を与える必要があるため、スクリプトに任せるが吉だと思う。

何に使うの? 感はあるが……

var extend = function(superClass, subClass) {
	var list = superClass.prototype;
	for(var key in list) {
		subClass.prototype[key] = list[key];
	}
};

var com = com || {};
com.hiyoko = com.hiyoko || {};

com.hiyoko.Hiyoko = function(){};
com.hiyoko.Hiyoko.prototype.hiyohiyo = function() {
  console.log('hiyohiyo');
};

com.hiyoko.Hitsuji = function(){};
com.hiyoko.Hitsuji.prototype.melemele = function() {
  console.log('melemele');
};

extend(com.hiyoko.Hiyoko, com.hiyoko.Hitsuji);

var sheep = new com.hiyoko.Hitsuji();
sheep.hiyohiyo();

prototype を for in で回して挿入しているだけ。

タイトルそのままです。長男の一歳の誕生日でした。妻が息子のためにケーキを作ってくれました。

食パンとホワイトソース、バナナとにんじんで作ったとのこと。

第二子が産まれました。体重は未熟児をすれすれで超えてきたところ。長男もそうだったので、母体に少しでも負荷をかけまいとしてくれているのだろうか。良い子達である。

なお、産まれてくる前夜、私は趣味の TRPG をやっていた。しかたないでしょ、予定日よりも18日早く生まれてくるなんて思わなかったよ……

ディレクトリトラバーサルと SQL インジェクションってどう違うの? という話をちょっと前にもらったのでそれぞれについて書く。

共通点

ちょっと知っている人なら全然違うじゃないか、と思う気もするのだが、ゆっくり見ると似ている点もある。

• 開発者が想定していなかった入力によって発生する
• 本来の操作ではアクセスされない領域にアクセスされる
• アクセスされた領域を参照されたり、改ざんされたり、削除されたりする

違う点

『本来の操作ではアクセスされない領域』が両者の間で異なる。

ディレクトリトラバーサル

Directory Traversal、日本語ではディレクトリ横断という意味になる。

例えば、サーバに設置されたアプリケーションが次のような構造だったとしよう。

┏━━━━┓
┃ユーザー┃┌───────────────┐
┗┳━━━┛│アプリケーションのあるサーバ　│
　┃　　　　│　　　　　┏━━━━━━━━┓│
　┃　　　　│　┏━━━┫ファイルシステム┃│
　┃　　　　│　┃　　　┃(Root)　　　　　┃│
　┃　　　　│┏┻━━┓┃├novel　　　　 ┃│
　┗━━━━┿┫アプリ┃┃│├novel1.txt　┃│
　　　　　　│┗━━━┛┃│└novel2.txt　┃│
　　　　　　│　　　　　┃└secret　　　　┃│
　　　　　　│　　　　　┃　└secret.txt　┃│
　　　　　　│　　　　　┗━━━━━━━━┛│
　　　　　　└───────────────┘

小〇家になろうとかカク〇ムみたいな小説を公開するアプリだとしよう。ユーザはアプリに読みたい小説のファイル名を送信する。例えば novel1 が読みたかったら novel1.txt と要求を送るわけだ。するとアプリはファイルシステムの novel ディレクトリからその小説のデータを取ってきてユーザに送り返す。

ここで問題になるのはユーザの入力が ../secret/secret.txt だった時だ。こちら、ファイルタイトルの通り機密ファイルであり、ユーザには見せられない。しかし、もしもディレクトリトラバーサルに対する対策が無ければこのファイルは容易に閲覧されてしまう。

このようにして本来アクセスされるべきでないディレクトリ (ないしファイル) にアクセスされてしまうのがディレクトリトラバーサルである。

対処法として以下が考えられる。

• そもそもファイルアクセスを可能な限りしない。小説の本文情報は DB に入れておく
• やむを得ず行う場合(皆無では決してないだろう)、アクセスに使うパスをきっちり管理する。
  パスを DB に格納しておいてユーザにはパスに対応するキーを入力として入れてもらうとか
  ユーザの入力をバリデーションするとか
• サーバ側のファイルアクセス権限を適切に設定し、アプリケーションを動かしているユーザの権限ではアクセスできないようにする

SQL インジェクション

SQL Injection、日本語で SQL 注入といった意味になる。その名の通り、SQL を注入するという攻撃であったり、それをできてしまう脆弱性であったりを指す。

分かりやすい例を示す。以下のような SQL を発行するとしよう。
'SELECT * FROM NOVELS WHERE TITLE = "' + userRequestNovelName + '"'
この userRequestNovelName が曲者である。これで想定されているのは先の例と同じくユーザの入力が novel1 だとかであることである。ユーザの入力が novel1 ならば、次の SQL 分が完成する。
"SELECT * FROM NOVELS WHERE TITLE = novel1"

では、ユーザの入力が "; DROP TABLE NOVELS; とかだったら? 実行される SQL 文は以下のとおりである。
'SELECT * FROM NOVELS WHERE TITLE = "";
DROP TABLE NOVELS;"'
2文が実行されることになる。しかも2文目は実行されたら相当まずい。

これへの対処にはプレースホルダーという方法が有効だが、説明が面倒なので省略する。Java の PreparedStatement クラスがおそらくは有名か。

もう一つ似たようなもの OS コマンドインジェクション

名の通り OS のコマンドを注入できる。これで rm -rf / とかされたら大参事である。