by shigemk2

当面は技術的なことしか書かない

シンボリックリンクからの被参照

Linux

特定のファイルがシンボリックリンクを貼られているかどうかを知りたい。

ポイントはfind -type lとreadlink

find -type l でシンボリックリンクのファイルを探す。readlinkでリンク元を探す。

find <検索対象のディレクトリ> -type l | while read LINK; do
readlink "$LINK" | grep -Fx <検索対象のファイル> >/dev/null && echo "$LINK"
done

シンボリックリンクからの被参照を調べたい 【OKWave】

SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか #v_night

勉強会

どぅるぱる

PHPにしては綺麗でSecureなCMS

Drupalの脆弱性

Drupageddon

  • SQLインジェクション脆弱性(非常に攻撃しやすい)
  • すごくやばい
  • 10/15 に発表
  • 時間内にパッチを当てないと攻撃されたと思え
select * from users where name = 'admin' and status = 1

name==user1&name==user2

select * from users where name = 'user1' and name = 'user2' and status = 1

バインド値

連想配列が使えるので、キー名をつけるとプレースホルダーにキー名がつく

プレースホルダーはエスケープできない

空白つきのキー

ログイン前SQLインジェクション

https://www.jpcert.or.jp/at/2014/at140042.html

ライブSQLインジェクション

巧妙に細工されたリクエスト DoS

  • パスワードを長くしてアクセスするとApacheの負荷が爆上がりする
  • 100万バイトのパスワード
  • 並列度を上げると倍率ドン
  • パスワード値が長いとハッシュ計算にものすごく時間がかかる

→バリデーションしようや

Drupalとバリデーション

  • 入力値検証とセキュリティ セキュリティが主目的ではないがセキュリティが良いことになることもある
  • 入力値検証はセキュリティ対策としてはあてにしない
  • 転んだ時の杖

まとめ

  • Drupalはログイン処理でバリデーションをしていない
  • Drupalはミクロの対処にこだわっている
  • Drupalは頑なにバリデーションを拒否していない
  • セキュリティ面からみると 局地では役立つが根本対策ではない
  • バリデーションはアプリケーション仕様をもとにやっとくと転ばぬ先の杖になりうる
  • 淡々とバリデーションをやればセキュリティ対策になりうる

RDBにおけるバリデーションをリレーショナルモデルから考える #v_night

勉強会

MySQLのサポートエンジニア

RDBにおけるバリデーションってなんだろう

リレーショナルモデルにバリデーションはない

ないが、constraintはある(制約)

constraint

評価した結果真となる条件式

  • type constraint
    • データ型が満たすべき条件 ドメインの定義
  • database constraint
    • データベース内のデータが満たすべき条件
    • 外部キーはこの一種

ドメイン

  • データ型のことをドメインという
  • 属性(カラム)が取りうる値の集合
  • 属性の値は、ドメインの要素の一つである
  • 属性の値は予めドメインに登録されている
  • そうなるようにドメインを設計する

どうやってドメインを表現するか

  • ドメインを集合として表現することは不可能に近い
  • 文字列で表現するデータが難しい
  • データサイズが大きい

  • ドメインの要素数が膨大になる

  • 列挙できるがデータサイズが大きいもの

  • 未知の値が多すぎて対処できない
  • フリーダムすぎるもの

→これらをドメインとして表現するのは不可能

妥協案 ドメインを制約で表現

  • SQL上で使用できるツール
  • check制約
  • create type
  • トリガー

  • テーブル+外部キー制約

  • 制約で、テーブルに格納するデータをフィルタリングする

データの危険性を鑑み、バリデーションが必要なのでは?

DBの出力→アプリへの入力

  • アプリケーションへ入力されたデータは適切にバリデーションしましょう
  • RDB側でバリデーションは必要なくって、アプリでやってくれ
  • RDBで出来るのは制約

ドメインの設計は超重要

  • 正しく設計すれば、アプリケーションによるバリデーションの手間が軽減される
  • 数値は数値型を
  • check制約で取りうる値の範囲を絞り込む
  • フリーダムなデータはアプリ側で確実にバリデーションを

本当に正しい値か

  • 運用設計は重要
  • データが正しいかどうかを確認するのはアプリケーションの運用者
  • ホワイトリスト方式でドメインを実装しても、この問いは完全には消え去らない
  • ユーザーのオペミスは十分にありうる

SQL≠リレーショナルモデル

この２つはちゃんと対応していない

  • リレーショナルモデル 集合論 すべて集合 集合にもとづく演算
  • SQL データベース操作言語 selectに盛り込まれたリレーション演算 モデル以外のデータの扱いおよび操作も可能

リレーショナルモデルであつかえないデータがある

  • 現実世界のアプリケーション
  • リレーショナルモデルに適合するデータとそうでないデータが入り乱れている
  • リレーショナルモデルには定石がある
  • 無理に実践すべきではない

RDBにおける制約とバリデーション

  • 制約: リレーショナルモデルの世界
  • バリデーション: リレーショナルモデルの外側の世界
  • アプリケーションと同じようにバリデーションが必要

プロシージャ内でprepareするべからず

まとめ

  • RDBにあるのは制約であってバリデーションではない
  • RDBまわりでバリデーションが必要なところ
  • アプリケーションへの入力
  • バリデーションはアプリケーション側への課題
  • リレーショナルモデルに沿わないデータやロジック

Javaでのバリデーション 〜Bean Validation篇〜 #v_night

勉強会

なぜやるのか

  • 人間なのでヒューマンエラーはつきもの
  • 壊れたデータはマーケに生かせない

どうやってやっているのか

Bean Validation

Bean Validationとは

JavaBeansのバリデーションのためのJavaのソフトウェアフレームワーク

遠隔

  • 2009 1.0
  • 2013 1.1

JSR

何がうれしいのか

あらかじめよくつかうチェックが用意されている(constraints) POJOに対してテストが書ける

Constraintsの例

  • @NotNull
  • @Pattern

など

一般的なバリデーションの話

  • 単項目チェック ひとつの項目に対するチェック(ちゃんと特定の項目がセットされていますか)
  • 相関チェック(男って選んでいるのに妊娠中って選択できないようにする)

コード例

@NotNull 単項目チェック

@Test

@RequestMapping

サンプル

Tips

  • 普通にやるとバリデーションが行われる順番はランダムだが、バリデーションの順番を制御することもできる
  • メッセージはプロパティファイルに外だし可能
  • プロパティファイルのエンコードはISO-8859-1

Webアプリケーション開発におけるValidationの変遷。今日求められているValidationとはなにか? #v_night

勉強会

バリデーションをどこでやるか問題

バリデーションをどういうふうにやってきたか

  • Amon2
  • FromValidator::Lite

Validationの歴史

  • Client Side
  • Controller
  • Model(外せない)

Sledge::Plugin::Validator

http://sourceforge.jp/cvs/view/sledge/Sledge-Plugin-Validator/

Modelが通らなかったらException

頑張ってjQueryでぶっこむのがしんどい

コントローラーでのバリデーションを懇切丁寧にやる必要がなくなってきた

modelでのバリデーションを中心にする

Client

Model(通らなかったらExceptionをthrow)

JSON APIの全盛の時代

JSONを受け取ってJSONで返す

JS書く人のほうがスケジュールがカツカツになるので保護するひつようがあったりする

入り口と出口でバリデーション

JSONの入力はBeanValidation

コードでどうにかしたほうが楽

Javaでやることが多くて、JSやObjective-Cしか書けない人にとっても読んでくれる気がする

(JSON Schemaよりも読みやすいかも)

Perlだと拒否反応出る人多いらしい

今の時代頑張ってエラーの状態を細かくHTMLで表示するより機械的に出してあげたほうがいいんじゃないかなっていうやつ

JSON Schemaとか手で書くのはばかばかしい

クライアント側のコードを補完きかせてバリバリ書く

社内向けのやつだったらそのクラスをそのまま依存関係に追加できて楽

最近はmicroservices全盛 時代はBeanValidation

LT #v_night

勉強会

jQueryでValidation最高

http://jqueryvalidation.org/

jQuery Validatoin Plugin

QUnit

jQuery Validation Plugin

つらいので通し番号をつけてごまかす

  • jQuery Validatoin Plugin便利
  • そこまで頑張る必要はないよね

focuslight-validator で Sinatra Application の ヴァリデーション

  • Growthforecast
  • Focuslight(RubyClone)

WebApplicationフロントエンドValidation

チャットワークでJSを書いている

フロントエンドValidationは安全ではない

ロジックの分散

ロジックでそれぞれ実装することも

専用APIを作る

Validatoinをどっちでやるの？サーバサイド？クライアントサイド？

Rails Context Validation

RailsのValidation

  • if unlessつらい
  • onをつかう
  • 設計を見直す

Validation nightで発表しました。 #v_night

勉強会

発表枠が空いていたのでLTをやりました。

LTで使用した資料はこちらです。

自作JSライブラリでvalidationをごにょごにょする！ @shigemk2

徳丸先生やら漢のコンピュータ道の方やらそうそうたるメンバーが集まる恵まれた環境からクソみたいなLTをやってしまったことを比較的後悔はしています。

全体的なテーマとして、

  • バリデーションでセキュリティの担保は出来るか
  • DBでバリデーションするよりアプリケーションでバリデーションしたほうがよいのではないか
  • バリデーションするならサーバ側でやるべきか、それともクライアント側でやるべきか

というアーキテクチャ寄りのとても濃い内容で、良い知見になったと思います。僕の技術力と頭の回転の遅さで、それが明日からすぐ使えるかというとかなりクエスチョンマークがつきますが、アーキテクチャの話はためになると思いました。それはノウハウの近視眼的な尺稼ぎじゃなくて数年後役に立つ知見ですから。

で、僕の話は仕事でバリデーションJSライブラリを自作したという話をしました。

「バリデーションは正規表現だ！」という特大のマサカリが飛んできそうなテーマをゴリ押しして喋りましたが、正規表現は複雑でtypoで死にそうなのでライブラリに押し込んだほうがいいという初心者レベルのアーキテクチャの話をしました。

なお、8月からずっと毎月1回以上はどこかしらの勉強会で発表するという縛りを設けており、Twitterを眺めてみても「前に○○で発表した人だ」というつぶやきが散見されるので、僕のHNは「しげえむけーつー」じゃなくて「しげまーくつー」であるという認識が少しずつ広まっていっているのではないかと思いました。

織田裕二のコスプレは控えています。