![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
ポケスタのスペシャル・テクニック「等」を参考に、
「そんな設定もあったなぁ。」みたいな。
「そんな経路もあったなぁ。」みたいな。
メールには以下のような経路がある。
USBメモリに仕込んだマルウェア系等が攻撃経路になる。
OA-LAN → VDI-LAN → System-LAN
利用者LANと分離することで、
利用者PCのマルウェア系感染による攻撃を防ぐ。
例外的にデメリットが多い。
集約して起きる問題
集約で解決できる問題
プロトコル上の脆弱性と、暗号化通信。
CONNECT www.example.com:443 HTTP/1.1
パスワード・クラック中のオンライン攻撃
ログイン試行系に関連し
よりセキュアに（SSHなど）。
認証カードも、2要素目（have）であることが多いかな。
（セキュア・コーディング系を含む）
→ 新たな脆弱性。
「マルチスレッド環境下でテストする。」
だと思ったが、
「デバッガを使用して、並列実行する。」
（意図的に、高確率で、競合を起こさせる）
みたいな回答だった。
※ デバッガはパラで動かんだろ...とか思いながら。
※ 誤検知はポジティブ
Android OSに対し責任を負う携帯メーカーの手により、
端末出荷時点ではrootを含む特権ユーザの存在は隠されている。
※ ファイル共有に関してはガイドラインが存在する。
※ .NETにはCASというモノが在ったが、今は無い。
（フィルタリング不可）のような問題が発生し得る。
ヒープ・マネージャの仕様によるが、
アドレスのランダム化によって攻撃が成功し難くなっている。
※ なお、BOF系の攻撃への対策は、効果無し。
Access-Control-Allow-Credentials: true
JavaScript系を除く。
../../../../../ ...
..\..\..\..\..\ ...
近年、下火らしい。
捻りの無い、そのまんま。だから？
組織でISMSを実践するための規範
物理的攻撃は、結構、想定外。
情シス的に常識。
受信者の自アドレスをヘッダに含まないケースがある。
経路系、暗号系とマルウェア系、
セキュア・コーディング系など、攻撃手口に関連したもので多い。
str = str.replaceAll("(?i)https?://", "");htt[https://]ps://
※ BYODのデバイス ≒ 多種の個人所有機
コチラと大差なく、素直な問題が多い。
'() { xxxx; }; echo vulnerable'env x='() { xxxx; }; echo vulnerable' bash -c set
vulnerable ← シェルコマンド（echo vulnerable）実行の結果
BASH=/bin/bash ← シェルコマンド（bash -c set）実行の結果
（省略）
x () ← 関数定義
{
:
}
