公式サイト

https://fortee.jp/phpcon-2019
今年はBeyondがテーマになっています。

PHPの今とこれから2019

資料: https://www.slideshare.net/hirokawa/presentations

歴代のスライド資料あげました
- 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の辛み
- オレオレフレームワーク　※遅くはないし悪くもない
- 静的解析ツールは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/

知見のない技術スタックをプロダクション導入するエンジニアの導入戦略

資料: 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を使っていた -> オープンリバースプロキシになっていた
リスクアセスメントの方法
- ベースラインアプローチ例:徳丸本に習ってやりましょう
- 非形式的アプローチ例:徳丸さんに来てもらいましょう
- 詳細リスク分析ベースラインで捉えられないものを考えましょう
業務レベルでの脅威分析表を作れるかどうか
- https://www.ipa.go.jp/files/000052459.pdf