20150704 icst 2015-maruwakari_day_matsuo

49
Web and App Testing ICST 2015 まるわかりDay! 松尾和昭 (@Kazu_cocoa)

Upload: kazuaki-matsuo

Post on 07-Aug-2015

383 views

Category:

Software


0 download

TRANSCRIPT

Web and App Testing

ICST 2015 まるわかりDay! 松尾和昭 (@Kazu_cocoa)

全体• Behind an Application Firewall,Are We Safe from

SQL Injection Attacks ?

• Using Multi-Locators to Increase the Robustness of Web Test Cases

• Understanding the Test Automation Culture of App Developers

• Detecting Display Energy Hotspots in Android Apps

Behind an Application Firewall, Are We Safe from SQL Injection Attacks ?

以下の論文を参照しています http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7102581

概要• Web Application Firewallにより、SQL Injectionを防

ぐ重要性が高まっている

• 攻撃者と防御者はいたちごっこ

• 効果的に数をこなして、より多くのSQL Injectionを事前に検出し、攻撃を防いで行きたい

導入• Web Application firewallsはオンラインシステムを攻撃から守るためには

欠くことのできないもの

• 新しい攻撃方法、それを防ぐ方法がイタチごっこのように早く表れている

• この研究では、Web Application FirewallとSQL Injection攻撃に焦点を当てている

• 機械学習を用いてSQL Injection攻撃を仕掛け、穴を見つける

• ML-Drivenと呼ばれる手法が提案手法

• ModSecutiryに対して提案手法を試し、有効性を確認している

• https://github.com/SpiderLabs/ModSecurity

用語• SQL Injection Vulnerabilities

• 不正にSQL文を実行する攻撃

• Web Application Firewall

• OSI参照モデルでいうApplication層におけるFirewall

• network層のものではない

• 文字列パターンのブラックリスト形式でブロックすることが多い

方法• ML-Driven

• 主に、BOOLEAN、UNION、PIGGY(SQLのunion query family)を対象に文法を定義

• 部分的に文法を変異させていくことで、テストケースとなるSQL文を生成していく

• 攻撃が通ったもの、通ってないものにラベルをつけ、学習しながらSQL文の生成

• search-base auto genrationなどの論文を参考にしていた

実験環境

ModSecurity

Attack

SOA based web app

java/servlet

customer relationship

web app

HotelRS

Cyclos

SugerCRM

結果:性能 B and D 変異させる度合い

B: 10 D: 100

結果:生成されるテストケース

まとめ1• この論文では、機械学習を取り入れたテストによりSQL

Injectionの脆弱性を発見する方法を提案している

• テストケースの自動生成含む

• 攻撃が成功/失敗したところから、異なる攻撃が成功するまでのテストケースの変異も取り入れているところが特にユニーク

まとめ2• ML-Driven

• SQL Injectionの特定を効率的に行っている

• テストケースをML-Drivenなしでランダムで作成するときに比べ、より良い性能を発揮している

• 数多く実施することで、より多くの成功するSQL Injectionを特定できることが期待されるため、それらを修正することができるようになる

Using Multi-Locators to Increase the Robustness of Web Test Cases

以下の論文を参照しています http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=7102611

概要• Webテストのテストスクリプトでは、Web locatorを使っ

て描画されている要素を特定するが、locatorは変更に弱い

• 壊れた場合、人手で修正する必要がある

• multi-locatorを使うという、壊れにくい、人手による修正が小さな労力で済む方法を提案する

• 保守性の向上

導入• Webテストのためのテストスクリプトでは、GUI要素を特

定するためにWeb locatorを使うことが多い

• Web locatorは大事だが、開発する上で壊れたらlocatorを修正しなければいけない

• この研究では、”multi locator”と呼ぶlocatorを提案する

• 複数のlocatorの中から、どのlocatorが正しいのか、を投票によって決める

Web locatorについて

• Web elementの特定手段

• HTMLのDOMに付随する付加情報をもとに識別する

• attributes、テキスト、XPathなど

• この研究では、XPathをもとにしたlocatorsを考える

• FirePath、Selenium IDE、ROBULA+など複数のアルゴリズムで取得することができる

XPath locators

Broken XPath locators

multi-locator• single locator(1つの要素のみ)

• 1つのWeb elementに1つのlocatorを含ませる

• multi-locator

• 異なるアルゴリズムにより生成されたlocatorの集合を1つのWeb elementとみなす

• automatic repairを持つ

• broken locatorとなったlocatorに対して、voteされた値を設定しなおす

multi-locator

結果: アルゴリズムごとのlocatorの壊れ具合

結果: locatorの壊れ具合

まとめ• Web elementを取得して、Webのテストスクリプトを書くことでテスト自

動化を図ることが多い

• locatorが壊れたら手動で修正する必要がある

• locatorを取得するアルゴリズムは、それぞれが異なる利点/欠点を持つ

• multi-locatorを提案し、変更に強い、locatorを用いたテストスクリプトを実装できるようにしたい

• 保守性向上

• 研究における結果では、multi locatorはsingle locator(ROBULA+)と比べて29.5%も壊れにくくなったという結果がでた

Understanding the Test Automation Culture of App Developers

以下の論文を参照しています http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=7102609

概要• スマートフォン向けアプリケーション開発において、開発者

の間におけるテスト自動化の文化を理解したい

• 文化を理解し、どのような問題に直面しているか知りたい

• Android開発者コミュニティが主な対象で、Windows開発者コミュニティと比較しながら違いを分析する

• 将来、開発者支援ツールの開発に役立たせたい

導入• 近年、スマーフトフォン向けアプリケーションの開発・利用が拡がっ

ている

• その開発はWebベースのアプリケーションと大きく異なる

• 開発環境、ツールなど

• 何かスマートフォン向けアプリケーション開発に対してテスト自動化などの方面で貢献したいが、何が問題か研究しているものがない

• Android開発者に焦点を当て、現状を知るための研究・調査が今まで無かった

研究内容の概要• F-Droidから600以上のアプリを得、その開発者にテス

トに関するアンケートをとる

• Android開発者。127名から回答があった。

• Windows開発者に対して同様のアンケートをとる

• コミュニティ間の違いを知る

• 考察

※F-Droid: Free/OSSなAndroidアプリを配布するサービス

Android Community

テストケースの量

アプリのコード数とテスト

アプリとアプリ開発者数

Windows Community

テスト自動化ツールの使い道

テストするにあたって直面している課題 (Android開発者との比較)

まとめ• Android開発者における、テスト自動化への取り組みと課題を

Microsoft開発者と比較することで知ることができた

• 対象となったAndroidアプリのうち、全体の14%がテストコードを持ち、そのさらに9%のみがカバレッジ40%を超える状態だった

• Android開発者の多くはJUnitなど様々なツールを使っているが、マニュアルテストがそれ以上に主力になっている

• 組織的なサポート、ドキュメントなど、テストツールに不足している点が挙がった

Detecting Display Energy Hotspots in Android Apps

以下の論文を参照しています http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7102585

概要• モバイルアプリにおける電池の消費を下げるために、ア

プリの画面単位で電池消費の大きなDEH(Display Energy Hotspot)を検出する方法を考えた

• まだα版だが、dLens という名前でライブラリを開発

• この方法自体は自動化できるため、ソフトウェアエンジニアを必要としないで実施可能

導入• モバイルアプリにおける電池の重要性は高い

• ディスプレイや、通信にかかる消費電力が大きい

• ディスプレイ技術は発達し、基板としてはより省電力になってきているが、どんな色を表示するか?というアプリ側制御によってもディスプレイの消費電力は左右される

• この問題に対して、任意のアプリを使っているときの、ディスプレイの消費電力の最も消費の大きなDEHを見つけ出してアプリを修正することで、結果としてディスプレイの消費電力を下げる方法を研究する

• 398のAndroid marktに存在するアプリに対して提案した手法を適用することで、DEHをいくつか見つけ出すことができた

全体像

• 画面単位でスクリンショットを取得する

• 取得したスクリーンショットからCTS(Color Transformation Scheme)を生成する

• Web Applicationとして電力消費が効率的になる色合い

• DEP(Display Energy Profile)とCTSを掛け合わせた画像と、もとのスクリーンショットを比較して消費電力の差分を求める

• 消費電力の大きなスクリーンショットから順にランク付けされたUIの結果を出力する

テスト対象の一例と作業時間

作業中の消費電力

デバイス間の差異

Galaxy S2の結果

Tc: CTS生成にかかった時間 Te: 画像比較にかかった時間 Overall: Tc + Te Per UI: 1スクリーンショットごとに要した時間

398個のアプリのうち、 DEHsが大きかったもの

まとめ• アプリの色合いを調整することで、アプリ利用時の消費

電力を抑制する方法を提案

• dLensという名前でツールを実装し、398アプリに対して実際に適用、DEHsを計測した

• 効果がありそうなことを確認

終わり