Security Links

Oct 21, 2017 | Comments

Security関係のLinkをまとめました。はてぶにすればいいのに > 自分

あー、勉強しないと。

Knapsack Problem

Oct 20, 2017 | Comments

ここ最近、Knapsack Problemが流行っている感じがしています。

応用情報技術者過去問題平成29年春期午後問3では基本「全探索」、改善提案が「枝刈り」でしたが、それでは全然不十分です。この問題は要するにKnapsack Problemのちょっとした変形で、code量もさしたることなく書けますし、折角FEではなくAPなのだし、日本の若者のためにも、Knapsackで書くよう誘導すべきだったのでは、と「禿げしく」思ったものでした。

すると、今度は応用情報技術者過去問題平成29年秋期午後問3でKnapsack Problemを正面から出してきましたね。0-1ではなく普通の。ぼくは前回のrevengeではないかと思ってみています。問題自体は、あまりにも普通のKnapsack Problemなので、ツッコミようがなくてつまんなかったデス。

この他にアジアでも。そっちは0-1でした。

References

ちなみに日本語では「ナップザック」、登山用語はドイツから入ってきたから、です。

Robolectric + PowerMock

Oct 17, 2017 | Comments

Robolectricのquick startは、本家が詳しい。

build.gradleに、以下が必要(Android Studio 2系の場合)。

testCompile 'org.robolectric:robolectric:3.4.2'
testCompile 'org.robolectric:shadows-multidex:3.3.2'
testCompile 'org.powermock:powermock-module-junit4:1.7.3'
testCompile 'org.powermock:powermock-module-junit4-rule:1.7.3'
testCompile 'org.powermock:powermock-api-mockito2:1.7.3'
testCompile 'org.powermock:powermock-reflect:1.7.3'
testCompile 'org.powermock:powermock-classloading-xstream:1.7.3'

Test Classは、Android Studioで開いた実class java fileのpublic class CLASS名のところで黄色いヒントをclickしてCreate Test classを選択、JUnit4で作成
既存test classのWhiteboxはorg.powermock.reflect.Whiteboxで置き換え
既存test classの@RunWithのMockitoJUnitRunnerはorg.mockito.junit.MockitoJUnitRunnerで置き換え
org.mockito.exceptions.misusing.UnnecessaryStubbingException:というwarningが出るようになったので@RunWith(MockitoJUnitRunner.Silent.class)にすると解消
cf. How to resolve Unneccessary Stubbing exception
RobolectricなTestは、1.@RunWith(RobolectricTestRunner.class) 2.activity = Robolectric.setupActivity(SomeActivity.class);でActivityを起動
RuntimeException: Multi dex installation failedと言われるのでshadows-multidexが必要
cf. Robolectric と Multidex でテストが落ちる問題の対応
static methodのmockはPowerMockと。@RunWithがかぶっちゃうよ、どうしよう! → 本家に解説あり。要は、@PowerMockIgnoreでmockito、robolectric、android標準classesを除外、@PrepareForTestでstatic methodを持つclassを指定し、@Ruleを入れ(使わないのによくわからないが必要)、PowerMockito.mockStatic(...)で当該classを指定
NoClassDefFoundError: org/powermock/classloading/ClassloaderExecutorと言われるので、powermock-classloading-xstreamが必要
cf. version 1.5.5 java.lang.ClassNotFoundException: org.powermock.classloading.DeepCloner #597
NoClassDefFoundError: org/mockito/cglib/proxy/MethodInterceptorと言われるので、powermock-api-mockito2と2でないとならない
cf. Problem with org.mockito.plugins.MockMaker and loading MethodInterceptor #819
javax.xml.parsers.FactoryConfigurationError: Provider ...DocumentBuilderFactoryImpl cannot be cast to javax.xml.parsers.DocumentBuilderFactoryと言われるので@PowerMockIgnoreに"javax.xml.*", "org.xml.sax.*", "org.w3c.dom.*", "org.apache.log4j.*"が必要
cf. Powermock + Mockito + Spring = DocumentBuilderFactoryImpl
org/powermock/default.properties is found in 2 placesと言われてerrorにはならないけどwarningが出るので、@PowerMockIgnoreに"org.powermock.*"も入れておく(試行錯誤の末なので参照なし)
AsyncTaskがあっても、特段その終了を待たずにtestが終了してしまう。Robolectric.getBackgroundThreadScheduler().pause();でAsyncTask#doInBackground()を止める必要がある(AsyncTask#onPreExecute()は実行される)。
ShadowAsyncTaskTest.javaを見ると、setUp()でRobolectric.getBackgroundThreadScheduler().pause();(とRobolectric.getForegroundThreadScheduler().pause();?)でthread止めて、asyncTask.execute()するとonPreExecute()が動き、次にShadowApplication.runBackgroundTasks();するとdoInBackground()、ShadowLooper.runUiThreadTasks();するとonPostExecute()が動く(ようだが、試してみるとShadowApplication.runBackgroundTasks()で返ってこなくなった。何故?!←これは単にAsyncTask中でdialog出して止まっていたため)

target class内でnewしているもののmockは、 PowerMockito.whennew(XXX.class).thenReturn(mock); だと、

org.mockito.exceptions.base.MockitoException: 
ClassCastException occurred while creating the mockito mock :
...
You might experience classloading issues, please ask the mockito mailing-list.

と言われて失敗する。

shadow classでもstatic methodのmockが出来る。PowerMock使わずとも良い様子。いちいちShadow class作って各method毎に@Implements書くのは面倒ではあるが、PowerMockを@Ruleして並存させると上述のようにclass loaderがどうのと言われて失敗したので、Robolectric一本で頑張った方がよさ気。PowerMock使わないならtestCompileもrobolectricとshadows-multidexの2つで済むし、PowerMock導入に伴って変更したMockito部分も変更不要になる。
Custom Shadow classesの追加でcustom TestRunnerは作成不要、単に@Configにshadows={ShadowXXX.class}と追記していけば良い。
Shadowについて。Android APIのclassesについては、全てShadowXXXというclassが揃っている(e.g. ShadowActivity)。まるっとmockしたものを返したい場合には、custom shadow methodでreturn Shadow.newInstanceOf(ShadowBluetoothDevice.class);で良い。
constructorもshadow出来る。constructorの場合には単にpublic void __constructor__(...){...}でよく、@Implementation annotationは不要(あっても害はない)。
extendsしてるclassのconstructorの場合には、super classのconstructorのshadowingも必要。さもなくばsuper classの当該constructorが実行されてしまう。また、super classのconstructorもshadowingする場合、当該Shadow classの方もextendsしないとClassCastExceptionに見舞われる。A extends BでAのconstructorをshadowingしたらBのconstructorもshadowingし、ShadowA extends ShadowBにする必要がある。
Shadows.shadowOf(myDialog).hasBeenDissmissed()といったようにUIの状態を取得できる。

context.getPackageManager().getLaunchIntentForPackage("package name")がRobolectricsでやるとnullを返しやがるのでヌルポで失敗しくさる。多くの人が困っている模様。cf. PackageManager#getLaunchIntentForPackage() returns null #747 ←これによると2.2の頃から。3.4からPackageManager周りはRobolectricPackageManagerがdeprecatedになって他と同じようにShadowPackageManagerを使えとMigrating from 3.3 to 3.4にはあるが、shadowOf(RuntimeEnvironment.application.getPackageManager());としても、versionを3.3に落としてRuntimeEnvironment.setRobolectricPackageManager(packageManager);としても、testにおけるApplicationPackageManager#getLaunchIntentForPackageはnullを返す。仕方なく、ShadowApplicationPackageManagerをextendsしてcustom PackageManagerを作ってみても、何を@implementsしたらいいのか。PackageManager.classでは効かないし(抽象クラス?なのでそれは仕方ないのだろう)、android.app.ApplicationPackageManager.classでは何故か名前解決に失敗してcompile出来ない。RobolectricPackageManagerTest.javaを見ると、notNullValue()でassert出来そうなのだが、うまく行かなかった(Step Overしてやってみても、そもそもShadowApplicationPackageManagerではなくandroid.app.ApplicationPackageManager#getLaunchIntentForPackageが何かにmethod callを取られて空で返している感じ)。色々探して結局諦めた。ホントは、↓というようにやりたかったのだが。

dialog.getButton(DialogInterface.BUTTON_POSITIVE).performClick();
assertThat(shadowOf(activity).getNextStartedActivity().getAction(),
               is("jp.ideacross.allcardia.main.SplashActivity"));

Robospock -> ElectricSpock or Spock for Android

せめてresourceの場所なりと。

RoboSpockですがちょっと更新が鈍いということでElectricSpock。但し新しい分情報少なし
Spock for Androidもあり
どちらも、directory structureがstandardでないとならない様子(要するにapp/src/main/java/...にsourceがありapp/src/test/groovy/...にSpock Testcodeがある)。build.gradleでのandroid.sourceSets.test.setRoot(...)は効かないようだった
要は、buildscript.dependenciesでclasspath 'org.codehaus.groovy:groovy-android-gradle-plugin:1.2.0'を指定、apply plugin: 'com.android.application'とapply plugin: 'groovyx.android'を指定、dependenciesにtestCompile 'org.spockframework:spock-core:1.0-groovy-2.4'を指定すれば素のSpock、testCompile 'com.github.hkhc:electricspock:0.6'ならElectricSpock、androidTestCompile 'com.andrewreitz:spock-android:2.0'ならSpock for Android(←これだけandroidTestCompileなのに注意)

という感じでしょうか。

Robolectric3 + RxJava(RxAndroid)1 + Retrofit2

RxJava + Retrofitなんて鉄板だからRobolectricによるtestなんてすぐ見つかると思ってたんですが、意外に手こずりました。要は、

Retrofit2に対してはMockWebServer(OkHttp3 の MockWebServer を使う)
RxJavaに対してはRxJavaHooks(RxJava のテスト(2): RxJavaHooks, RxAndroidPlugins)
MockWebServerは、例にあるように基本newしてMockResponseをenqueueしてurl(...)すればstartしてreturn valueにURL(http://localhost:XXXXX/←random port number)が入っているのでそれをRetrofitに食わせればいいのだけれども、URLをsetする部分はShadowの中なので、test classから直接食わせられず。なので固定port番号を使いたく、その場合server.url("/...");は不要で、
1
server.start(portNumber);
でおk
↑httpになるとisCleartextTrafficPermitted()まわりで失敗するようになった。これは、isCleartextTrafficPermitted() fails on OpenJDK 8 + Robolectric #2533にあるように、NetworkSecurityPolicyをShadowしてやればよい。
RxJavaのonNextやonCompletedが実行されない問題は、Robolectric.flushBackgroundThreadScheduler();ではなく、
1
RxJavaHooks.setOnNewThreadScheduler(s -> Schedulers.immediate());
によって別threadじゃなくmain threadで実行するようにすればおk
上記の話は、Retrofit2のService interfaceでObservable<...>を返す場合のもの。Call<...>を返す形にしてenqueue()してCallback<...>でonResponse()、onFailure()でhandleする場合には、こうは行かなかった(onResponse()もonFailure()も実行されない)。ShadowLooper.runUiThreadTasks()でうまく行くようなことを書いてある情報(Testing retrofit 2 with robolectric, callbacks not being called)もあったが、症状変わらず。OkHttpのMockWebServerとRobolectricでFragmentの動作をテストするにRetrofit2内で使っているOkHttpClient.Builder#newBuilderをshadowしてうまく行く話があったので、試すと確かにonResponse()が呼ばれた! ただ、今回ぼくは実classの方でnew Retrofit().newBuilder().client(new OkHttpClient().newBuilder().build())とかってclientmethodを使っておらずdefaultで裏でimplicitlyに生成されるOkHttpClientそのまま使っており、それだとnewBuilder()呼ばれないので、色々辿ってった挙句、okhttp3.Dispatcher#executorServiceをshadowして、前述のpageにあったようにすぐcommand.run()するexecutemethodを持つAbstractExecutorServiceclassを返してやると、うまく行った。Dispatcher#executorServiceってjava.util.concurrent.ThreadPoolExecutorをdefaultでは使っており、Androidのthreadとは違うから、uncontrollableだったんですね。考えてみるに、RxAndroidと違いRetrofitはAndroid専用ではないので、java.util.concurrentのExecutor使ってるのも当然ですか。

AccountManager with Robolectric(というかMockito)

基本的には、AccountManager.get(Context)はJUnit Test内でもtarget class内でも同じobjectを返すので、そのままassertion可能

ただ、例えばmanager.blockingGetAuthToken(...)でExceptionを起こさせたい時は、AccountManager manager = spy(AccountManager.get(application));したmanagerをgetSystemService(Context.ACCOUNT_SERVICE)でdoReturnするようにしたApplicationをspyして、そのapplicationをRuntimeEnvironment.applicationの代わりにねじ込む必要がある(Using mockito to mock AccountManager)。具体的には、

@Rule
public ExpectedException thrown = ExpectedException.none();
  :
Account account = new Account("any name", CarCloudAuthUtil.ACCOUNT_TYPE);
Application application = spy(RuntimeEnvironment.application);
util = new CarCloudAuthUtil(application);
AccountManager manager = spy(AccountManager.get(application));
doReturn(manager)
        .when(application)
        .getSystemService(Context.ACCOUNT_SERVICE);
manager.addAccountExplicitly(account, "any key", new Bundle());
manager.setAuthToken(account, CarCloudAuthUtil.AUTH_TOKEN_TYPE, "any string");
doThrow(AuthenticationException.class)
        .when(manager)
        .blockingGetAuthToken(eq(account), eq(CarCloudAuthUtil.AUTH_TOKEN_TYPE), eq(true));
thrown.expect(AuthenticationException.class);
thrown.expectMessage(new IsNull());

Exceptionのassertionは、@Test(expected=...)でも良いが、@Ruleでも書ける(JUnitでの例外テストの書き方)。その場合、Exception#messageがnullの場合のassertionはorg.hamcrest.core.IsNullを用いてthrown.expectMessage(new IsNull());とする(ExpectedException.expectMessage((String) null) is not working)。
mocking method実行時に他のことをしたい時には、when(mock.methodCall()).thenAnswer(m -> {...});とlambdaで書ける(mockitoとJMockitについてのメモ)。

Tomcat Vulnerability CVE-2017-12617

Oct 13, 2017 | Comments

Tomcatの複数の脆弱性(CVE-2017-12617, CVE-2017-12615 , CVE-2017-12616)が、範囲が広がって出てました。 readonly initialization parameterをfalseにしてPUTを有効化している時にaffectする(任意のjsp fileを不正にPUTしてから好き放題する)、とのことなので、きょうびはRESTでPUT多用するから影響範囲広いんでしょうか? 否、「default servletのinitialization parameter(具体的にはweb.xmlのservlettagのinit-param)でfalseを明示した時(defaultはtrue)なので、殆どのところはそんなことしてないから大丈夫なんじゃないでしょうか。実際、POCで試してみたところ、うちのsiteは(version的には範囲内ですが)Not Vulnerable to CVE-2017-12617と出ました。

$ python tomcat-cve-2017-12617.py -u http://localhost:8080

   _______      ________    ___   ___  __ ______     __ ___   __ __ ______ 
  / ____\ \    / /  ____|  |__ \ / _ \/_ |____  |   /_ |__ \ / //_ |____  |
 | |     \ \  / /| |__ ______ ) | | | || |   / /_____| |  ) / /_ | |   / /
 | |      \ \/ / |  __|______/ /| | | || |  / /______| | / / '_ \| |  / /
 | |____   \  /  | |____    / /_| |_| || | / /       | |/ /| (_) | | / /
  \_____|   \/   |______|  |____|\___/ |_|/_/        |_|____\___/|_|/_/

[@intx0x80]

Poc Filename  Poc.jsp
Not Vulnerable to CVE-2017-12617

Alpaca Algo

Oct 08, 2017 | Comments

こういうの、あったんですねー。すごいすごい。 Alpaca Algo、かつてのCapitalicoだそうですが、自分でindicatorを指定して、勝ちpattern(負例も!)を指定して、そうすると裏で超高速に事例を学習し、 back testまで速攻でやってくれるとは! 幾つか試してみましたけど、テキトーにやっても、 back testでプラスになったりするので、おぉー! と思ってはみたものの。 back testの期間をdefaultの3ヶ月ではなく、 1年とか、特に2016年を入れると、途端に物凄い成績悪くなります。なんでー!? 2016年って何か違ったんでしょうか。っていうか、2017年の方がおかしい? とにかく、何か違うようです。

patternに当てはまったら通知もしてくれるというので、試してみます。まだ本番への適用は怖い感じですが。

9日朝、2回通知来ましたけど、以降はさっぱり当たりませんでした。デモ取引では、10:05にentryして15:48現在まだ売買成立してません。ドル円上下15pipsなので、day tradeにはちょっと大きめの幅なんでしょう。

色々試してみると、

10〜20はpattern入れて、って書いてありますが、あんまり入れると取引回数少なくなる?
負例も入りますが、負例はいくら入れても学習対象としてcountされません。入れた方がいいのかどうなのか、よくわかりません。
back testでは、どのくらいの精度で当てはめてentryして、どのようにexitするかで当然成績は大きく変わってきますが、「全部お任せ!」にしておいた方が一番成績いいみたい、です。「最適な○○を最適化」とかって具体的には何やってんのかさっぱりですけど、グラフではなく数値で見ると、利食い損切りpipsがわかるので何となく。
売り・買い両方揃えないとダメかしらん。
範囲はどこまで指定したらいいのか、よくわからないですが、何となく学習してるのはindicatorがどうのというより値動き(ローソク足)だけっぽい? いやでも確かにindicatorの種類だけ変えると結果変わるのでindicatorも見てるんでしょうけど...

u-ryo's blog

various information for coding...