We tried to validate botfrei.de (See id 16 and 17 in domains table).

Both domain tokens are in index.html.

Domain token for id 17 is also stored as a file.

Nevertheless validation fails.

We tested between 08:05 and 08:10 this morning in case this helps.

The CoreAPI requires scanners to start scans.

I cannot see any CoreAPI call to manage them.

If this is not intended, we would at least need Instructions how to manually tweak the undocumented database.

Diese Route soll zusätzlich folgende Informationen ausgeben:

1. Zeitpunkt der Registrierung des Nutzers (des Tokens)
2. Zeitpunkt des letzten Scans

Möglichkeit, verschiedene Scanner einzeln zu starten, basierend auf einer ACL bzw. über die Business Logic, damit ein Free-Scan ohne Registrierung möglich ist.

ScanJobs update table "scans" by setting the status to "2" (again: No clear understanding what "2" means here).

I also can see that in ScanController.php this field is updated to contain "3".

Are you sure it is correct that every scanner updates this one field, possibly overwriting values from other scanners?

Please see scan_id 75. HEADER scanner didn't finish (for unknown reason) and so the scan cannot complete. The scan was started an 7:16, now it's 8:46.

Core-API soll nur den letzten Scan speichern, BL-API speichert die komplette Historie.

Überprüfung, ob das Token die übergebene Domain bereits verifiziert hat.

Bevor ein Scanner gestartet werden kann, soll überprüft werden, ob genügend Credits auf dem Token vorhanden sind.

Dies soll über eine Middleware realisiert werden

In CoreApi/app/Http/Controllers/ScanController.php

you have

        // dispatch each scanner to the queue
        ScanHeadersJob::dispatch($scan);
        ScanDOMXSSJob::dispatch($scan);
        ScanInfoLeakJob::dispatch($scan);
        // TODO: dispatch TLS-Scanner
        // TODO: Send Response

The consequence is that we have to compile the CoreAPI each time a new scanner is introduced or another scanner has to be decommissioned.

This does not meet the requirements as far as I know.

The scanners must be configurable. Best would be to have it in the database and have API Calls to add, remove, enable and disable them.

/token/add hat keinerlei Sicherheitsvorkehrung. Wenn also jemand eine kleine Endlosschleife gegen /token/add feuern läßt…

Before starting a scanner, database entries are created so that the results can be acceppted.

But when the scanner couldn't be started, the entries remain unchanged.

Especially the status remains at "2" (whatever that might mean) instead of being updated to something indicating "failed to start".

Request

POST /api/v1/token/add HTTP/1.1
Host: siwecos-core-api.dev
Accept: application/json
Content-Type: application/json
masterToken: wD7YVVc6v4IS8eeghVaTRC/x
Cache-Control: no-cache
Postman-Token: f1fae26e-a1b6-5f8a-6f9a-f231f9b58535

{
"aclLevel":1,
"credits":65536
}

! Response

{
    "token": "THe9eO22P0Fjx0WxZKffbRb2",
    "hasFailed": false,
    "message": "token successful created"
}

Store this token in Postman as mysite.dev's token.

Database

Query

select * from tokens where token = 'THe9eO22P0Fjx0WxZKffbRb2'

Result

Question

aclLevel is 0 but 1 was requested.

In

TranslateableMessage:
  required:
    - placeholder
  properties:
    placeholder:
      type: string
      description: human readable language placeholder name i.e. HACKED_FILE_FOUND
    values:
      type: string
      description: Key-value pairs that will be used within the language string

values should be an object of key-value pairs.

Request

POST /api/v1/domain/remove HTTP/1.1
Host: siwecos-core-api.dev
Accept: application/json
Content-Type: application/json
siwecosToken: THe9eO22P0Fjx0WxZKffbRb2
Cache-Control: no-cache
Postman-Token: d98d4108-bf38-1e43-a0de-256b7d42ec43

{ "domain":"http://mysite.dev" }

Response

{
    "domain": [
        "The domain has already been taken."
    ]
}

Question

Why did removal fail? Found a bug?

Currently I can register one domain endless times:

• http://my.do.main
• http://my.do.main/
• http://my.do.main:80
• http://my.do.main:80/
• http://[email protected]
• …

Das Übermittelte Token soll validiert werden, bevor ein Controller angesprochen wird.

Dies geschieht über eine Middleware.

Currently it seems to me that the integration of a new scanner is much more complicated than it need to be. As a matter of fact every scanner has to work according to a defined API. Due to this it should be sufficient to have the scanner's entry URL in order to utilize it. So the only thing which I would expect to configure is this URL in a configuration file.

Unfortunately this isn't the case. In order to integrate a new scanner you have to (possibly incomplete)

1. "use" it in ScanController.php
2. Dispatch it in the same file
3. Create a new job-php - seems the existing 3 are pretty much identical besides some names
4. add it to 2 autoload files (or is this done automatically?

Wenn #21 abgeschlossen ist, sollten die images evtl. im Docker-Hub bereitstehen, sodass ein einfacher Start via docker-compose realisierbar ist.

I just discovered the comment given in the subject in file ScannerController.php

This gives me a bad feeling… Is it a leftover or are the scan results really not sent to the business layer?

Beispielergebnisse im JSON-Format, die von den Scannern zurückgeliefert werden, sollen als Mock gespeichert werden, sodass für die Entwicklung kein direkter Scan-Aufruf benötigt wird.

Die Scanner sollten ein Docker-File beinhalten, sodass diese schnell und einfach genutzt werden können.

Benötigt für die Travis-Tests / Test-Setup

The Scan…Job.php files use environment variables without testing for their existance.

So they try to start a scanner even if the entry URL isn't configured.

Better log an errr/warning telling which scanner failed to be started.

Is it intended that domain verification happens just once?

I think a verification should be done either before each scan.

Otherwise a domain which changed owner could be scanned by an unauthorized person.

Tested by removing my token from my site.

Update: Even worse: A second run on verify fails, but does not change the database entry. Domain is still verified.

Aktuell warte ich auf Rückmeldung bezüglich der Übergabe-Parameter des Scanners.