公式サイト
https://fortee.jp/phpcon-2019
今年はBeyondがテーマになっています。
PHPの今とこれから2019
資料: https://www.slideshare.net/hirokawa/presentations
- 歴代のスライド資料あげました
- PHP7.4の次は8
- 2021年の後半(９月？)にリリースかも
- PHP7.xは80%程度利用中（会場内アンケート）
- データではPHP7.xは4割程度
- PHP5.xは57%(昨年は75%)
- 今年出たバージョンは３年後にはEOL
- 7.1のEOLは今日(2019/12/01)
- CVEが付いている修正はセキュリティの修正なので速やかにバージョンアップしたほうがいい
- PHP7.4は7.3より15％程度ベンチマークが改善
- ※体感はあまり変わらないが
- PHP7.4
- TypeHintingの追加
- Null許容型
- OpCacheのPreロードで高速化
- アロー関数
- ??=構文
- mb_str_split関数
- .演算子の優先順位 +のほうが優先される
- 弱い参照
- 継承した型に対してWarningが出ないように
- PHP8
- JITエンジンを活用 →より速くなる
Chatworkのシステムから学ぶレガシーなPHPの限界とレガシーからの脱却
資料: https://speakerdeck.com/shmurakami/phpcon2019
- レガシーコードの定義
- 修正/拡張/作業が非常に難しいコード
- PHPとScalaを使ってる
- PHPはレガシー 巨大なモノリス
- Scalaは分散システム志向 HBase/DynamoDB/Kafka
- ３年半前にPHPからScalaへのゼロベース移行
- PHPの辛み
- オレオレフレームワーク ※遅くはないし悪くもない
- 静的解析ツールは
PhpMetricsが動かせた
- なぜこうなった？
- スピードを優先した結果
- ビジネスが拡大したタイミングで仕様を厳格化しなかった
- 全体的なScala化に失敗し、部分移行になった
- 何が問題なのか
- データベースの分割 クライアント1万問題
- データベースのスケールに限界がある
- マイクロサービスは辛い
- まずはモジュール分割から
- チーム間のコミュニケーションも辛い
- ホラクラシー組織を検討中！
- レガシーなPHPの限界は、関連ツールの限界がきたとき
- ビジネスのスケールに合わせて適切なタイミングでリファクタリングしよう
PHPからgoへの移行で分かったこと
資料: https://speakerdeck.com/mahiguch/phpkaragohefalseyi-xing-defen-katutakoto
- 移行前は ALB->EC2(fpm)->DBなど
- FuelPHPを使用(メンテナンスが少ない)
- 移行後は NLB経由でコンテナでGo
- PHPとGoのmemcacheのライブラリが異なるためHashが合わない
- memcacheへアクセスするだけのGatewayコンテナを作成
- PHPerしかいなかったけど１０時間くらいでGo書けるレベルになった
- 記事推薦システムをPythonからGoへ移行
- 記事とユーザーをベクトル化してパーソナライズする
- PHPはプロセスを分けて並列化したが、Goは簡単にできる
- PHPは飽きるのでGoを書くとモチベーションが上がる！
- GopherはPHPの1/100くらいの感覚
- PHP/Pythonに戻すかも^^
- Chatworkさんみたいに５年も頑張れない、、。
思想と理想の果てに -- クリーンアーキテクチャのWEBフレームワークを作ろう
資料: https://nrslib.com/phpcon-2019-proposal/
- クリーンアーキテクチャはフレームワーク非依存
- この仕様をどこに実装したっけ？をなくそう
- ポートアンドアダプター
- ヘキサゴナルアーキテクチャ
- 空いているポートにアダプターを繋ぐイメージ
- DataAccessModuleに主導権を持たせず、BusinessLogicに持たせる
- クリーンアーキテクチャは内側が外側のことを知らない
- Entity
- ビジネスロジックをドメイン化したモジュール
- アプリケーションレイヤー
- ユースケースを提供する
- InterfaceAdapters
- コントローラ(コントローラ)、画面(プレゼンター)、ゲーム機(インタラクター)
- Framework&Devices
- ビジネスロジックに依存しない
- メリット
- 処理や出力を差し替えられる→画面なのかコンソールなのか変えられる
- モックの差し替え、例外を起こすビジネスロジックの差し替えでバグ検証
- 代償
- レスポンスがView(MVC)の場合にマッチしない
- めんどくさい
- Scafold機能欲しい
- PHP_Parser https://github.com/nikic/PHP-Parser
- まずはMVCを捨てる(!?)
- プレゼンターで、どうにかしてViewを描画する
- 戻り値をなくす Laravelだとミドルウェア機能で。
- プラグイン作りました
- https://github.com/nrslib/clarc-laravel-plugin
- プラグインだけどフレームワーク非依存なので組み込みが可能
知見のない技術スタックをプロダクション導入するエンジニアの導入戦略
資料: https://speakerdeck.com/hgsgtk/a-strategy-to-choice-no-knowledge-technology
- 技術選定の視点とは？
- 用件によって重視すべき点が変わる
- 運用実績がないものの方がマッチするケースがある
- 品質には外部品質と内部品質がある
- ユーザーに見えるか見えないか 可用性があるか
- 外部と内部でアプローチを考える
- 業務でやったことないと分からん
- いかに多く学びすぐに反映するか
- じゃあどうやって学ぶの？
- 学びのサイクルを観察する
- テストコードを設計道具として使おう
- 早期にデプロイして監視しておく
- バグに気づく
脆弱性から学ぶWebセキュリティ
資料: https://speakerdeck.com/hypermkt/study-web-security-from-vulnerability2
- 脆弱性の対策方法
- 根本的解決 完全根絶
- 保険的対策 影響範囲を限定させる
- ディレクトリトラバーサル
- ファイルパスをパラメータで受け付けない
- バリデーションする
- OSコマンドインジェクション
- セミコロンを利用してLinuxコマンドが連続して実行される
- 怪しい関数 -> system exec passthru shell_exec popen
- escapeshellargでエスケープする
- セッション管理の不備
- セッションハイジャック
- セッションIDの固定化
- セッションアダプション セッションIDを有効なセッションIDとして許可してもらうこと
- 認証が成功したら新しいセッションを開始する
オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法
資料: https://www.slideshare.net/ockeghem/phpconf2019
- キャンペーン21%還元！ -> 景品表示法違反で消費庁から呼び出し
- 20%にして解決 -> キャンペーン取り消しで不信感を与えてしまった
- パスワードスプレー攻撃で不正ログイン相次ぐ
- IoT機器からの攻撃 -> 多数のIPアドレスからの分散攻撃
- ユーザーIDを連番にしない、二段階認証をおこなう
- 秘密の質問は禁止
- パスワードの定期的変更の強制を禁止
- 2段階認証の実装不備で不正ログインが止まらない
- バイパスできた -> セッションIDにユーザーIDをセットしていた
- 未ログイン/2段階認証待ち/ログイン済み でセッションIDを作成
- ヘルプデスクにパスワードリセットされてログインできない
- 仮パスワードを登録済みのメールアドレスに送信する
- スマホアプリの端末上にパスワードが平文で保存されていた
- iOS: KeyChainに保存する
- Android: KeyStoreに保存する
- リジェクト警告を無視してアプリがストアから消えた
- 「Android」という単語をiOSアプリ内で使用してしまった
- OSコマンドインジェクションで不正アクセスされた
- 改竄検知で早期に発見された
- エスケープが漏れていた
- PHP7.4以降はproc_open関数で対策 シェル経由にならないため安全
- WAFのリバースプロキシがオープンになってAWSのIAMが漏洩した
- SSRF脆弱性という
- Apacheのmod_securityを使っていた -> オープンリバースプロキシになっていた
- リスクアセスメントの方法
- ベースラインアプローチ 例:徳丸本に習ってやりましょう
- 非形式的アプローチ 例:徳丸さんに来てもらいましょう
- 詳細リスク分析 ベースラインで捉えられないものを考えましょう
- 業務レベルでの脅威分析表を作れるかどうか