{
  "added": "2020-08-26T17:03:21.398Z",
  "info": {
    "contact": {
      "email": "support@probely.com",
      "name": "Probely Support",
      "url": "https://probely.com"
    },
    "description": "Probely is a Web Vulnerability Scanning suite for Agile Teams. It provides\ncontinuous scanning of your Web Applications and lets you efficiently\nmanage the lifecycle of the vulnerabilities found, in a sleek and\nintuitive ~~web interface~~ API.\n\n## Quick-Start\n\n### Authentication\n\nTo use the API, you first need to create a token (API Key).\nTo create a token, select a target from the drop-down list, go to the\n\"Settings\" page, and click on the \"Integrations\" tab.\n\nWrite a name for the API Key. For example, if you want to use the API Key\nfor travis,\nyou could name it \"travis\". In this example, we chose \"**example.com_key**\"\n\n![Creating API key][1]\n\n  [1]: assets/qs/create_api_key_1.png\n\n\n\nThe API key was created successfully:\n\n![API key created][2]\n\n  [2]: assets/qs/create_api_key_2.png\n\n\nOn every request, you need to pass this token in the authorization header,\nlike this:\n\n\n```yaml\nAuthorization: JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiJBRlNJQlp\n3elFsMDEiLCJ1c2VybmFtZSI6IkNIZ2tkSUROdzV0NSJ9.90UwiPGS2hlvgOLktFU0LfKuatNKm\nmEP79u17VnqT9M\n```\n\n\n**WARNING: Treat this token as a password. With this token, you have the\npower to fully manage the target.**\n\nIn the following examples, the token will be named as *PROBELY_AUTH_TOKEN*.\n\n\n### Scan target\n\nFirst let's view our target list:\n\n```bash\ncurl https://api.probely.com/targets/ \\\n  -X GET \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: JWT PROBELY_AUTH_TOKEN\"\n```\n\n\nFrom the results, we need the **target id**:\n\n```json\n{\n   \"count\":1,\n   \"page_total\":1,\n   \"page\":1,\n   \"length\":10,\n   \"results\":[\n      {\n         \"id\":\"AxtkqTE0v3E-\",\n         \"name\":\"test-site\",\n         \"desc\":\"\",\n         \"url\":\"https://test-site.example.com\",\n         \"settings\":\n            \"(...)\"\n         ,\n         \"stack\":\n            \"(...)\"\n         ,\n         \"verified\":true,\n         \"(...)\": \"(...)\"\n      }\n   ]\n}\n```\n\n\nNow we can send a request to start a scan on target id **AxtkqTE0v3E-**\n\n```bash\ncurl https://api.probely.com/targets/AxtkqTE0v3E-/scan_now/ \\\n  -X POST \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: JWT PROBELY_AUTH_TOKEN\"\n```\n\n\nAnd we get a response saying that the scan is scheduled: the status is **queued**, and we've got a **scan id**:\n\n```json\n{\n   \"changed\":\"2017-08-01T13:37:00.843339Z\",\n   \"started\":null,\n   \"completed\":null,\n   \"mediums\":0,\n   \"changed_by\":\n    \"(...)\"\n   ,\n   \"highs\":0,\n   \"status\":\"queued\",\n   \"id\":\"S6dOMPn0SnoH\",\n   \"created_by\":\n    \"(...)\"\n   ,\n   \"target\":\n    \"(...)\"\n   ,\n   \"created\":\"2017-08-01T13:37:00.843339Z\",\n   \"lows\":0\n}\n```\n\n\nUsing the scan id **S6dOMPn0SnoH**, we can pool the scan status:\n\n```bash\ncurl https://api.probely.com/targets/AxtkqTE0v3E-/scans/S6dOMPn0SnoH/ \\\n  -X GET \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: JWT PROBELY_AUTH_TOKEN\"\n```\n\n\nAnd we get a response saying that the scan status is now **started**:\n\n```json\n{\n   \"id\":\"S6dOMPn0SnoH\",\n   \"changed\":\"2017-08-01T13:38:12.623650Z\",\n   \"started\":null,\n   \"completed\":null,\n   \"mediums\":0,\n   \"changed_by\":\n    \"(...)\"\n   ,\n   \"highs\":0,\n   \"status\":\"started\",\n   \"created_by\":\n    \"(...)\"\n   ,\n   \"target\":\n    \"(...)\"\n   ,\n   \"created\":\"2017-08-01T13:37:00.843339Z\",\n   \"lows\":0\n}\n```\n\n\nThe possible statuses are:\n\n| Status | Name | Description |\n| ------ | ---- | ----------- |\n| queued | Queued | The scan is queued to start |\n| started | Started | The scan is currently running |\n| under_review | Under Review | The scan is complete but has some findings under review |\n| completed | Completed | The scan is complete |\n| completed_with_errors | Completed with errors | The scan is complete even after getting some error(s) |\n| failed | Failed | The scan failed |\n| canceled | Canceled | The scan was canceled |\n| canceling | Canceling | The scan is being canceled |\n\n\nDuring the scan, the keys \"lows\", \"mediums\", and \"highs\" will be updated\nwith the findings, as they are being found.\n\nAfter we get either the status **completed** or **completed_with_errors**,\nwe can view the findings.\n\n\n### Get vulnerabilities\n\nUsing the previous scan id **S6dOMPn0SnoH**, we can get the scan results:\n\n```bash\ncurl https://api.probely.com/targets/AxtkqTE0v3E-/scans/S6dOMPn0SnoH/ \\\n  -X GET \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: JWT PROBELY_AUTH_TOKEN\"\n```\n\nWe get a response saying that the scan status is now **completed**, and\nthat **45** vulnerabilities were found. **14** low, **11** medium and\n**20** high:\n\n```json\n{\n   \"id\":\"S6dOMPn0SnoH\",\n   \"target\":\n    \"(...)\"\n   ,\n   \"status\":\"completed\",\n   \"started\":\"2017-08-01T13:37:12.623650Z\",\n   \"completed\":\"2017-08-01T14:17:48.559514Z\",\n   \"lows\":14,\n   \"mediums\":11,\n   \"highs\":20,\n   \"created\":\"2017-08-01T13:37:00.843339Z\",\n   \"created_by\":\n    \"(...)\"\n   ,\n   \"changed\":\"2017-08-01T14:17:48.559514Z\",\n   \"changed_by\":\n    \"(...)\"\n}\n```\n\nYou can now view the results of this scan, or the target findings.\n\n\nLet's start with the scan results:\n\n```bash\ncurl https://api.probely.com/targets/AxtkqTE0v3E-/findings/?scan=S6dOMPn0SnoH&page=1 \\\n  -X GET \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: JWT PROBELY_AUTH_TOKEN\"\n```\n\n```json\n{\n   \"count\":45,\n   \"page_total\":5,\n   \"page\":1,\n   \"length\":10,\n   \"results\":[\n      {\n         \"id\":79,\n         \"target\":\n          \"(...)\"\n         ,\n         \"scans\":\n          \"(...)\"\n         ,\n         \"labels\":\n          \"(...)\"\n         ,\n         \"fix\":\"To fix an SQL Injection in PHP, you should use Prepared Statements. Prepared Statements can be thought of as a kind of compiled template for the SQL that an application wants to run, that can be customized using variable parameters.\\n\\nPHP's PDO extension supports Prepared Statements, so that's probably your best option.\\n\\nIn the example below you can see the use of prepared statements. Variables ```$username``` and ```$hashedPassword``` come from user input.\\n\\n```\\n$stmt = $dbg->prepare(\\\"SELECT id, name FROM users\\n                       WHERE username=? AND password=?\\\");\\n$stmt->bindParam(1, $username);\\n$stmt->bindParam(2, $hashedPassword);\\nif ($stmt->execute()) {\\n\\t$user = $stmt->fetch();\\n\\tif ($user) {\\n\\t\\t$_SESSION['authID'] = $user['id'];\\n\\t\\techo \\\"Hello \\\" . $user['name'];\\n\\t} else {\\n\\t\\techo \\\"Invalid Login\\\";\\n\\t}\\n}\\n```  \\n\\nAs an added bonus, if you're executing the same query several times, then it'll be even faster than when you're not using prepared statements. This is because when using prepared statements, the query needs to be parsed (prepared) only once, but can be executed multiple times with the same or different parameters. \\n\",\n         \"requests\":[\n            {\n               \"request\":\"(...)\",\n               \"response\":\"(...)\"\n            },\n            {\n               \"request\":\"(...)\",\n               \"response\":\"(...)\"\n            }\n         ],\n         \"evidence\":null,\n         \"extra\":\"\",\n         \"definition\":{\n            \"id\":\"xnV8PJVmSoLS\",\n            \"name\":\"SQL Injection\",\n            \"desc\":\"SQL Injections are the most common form of injections because SQL databases are very popular in dynamic web applications. This vulnerability allows an attacker to tamper existing SQL queries performed by the web application. Depending on the queries, the attacker might be able to access, modify or even destroy data from the database.\\n\\nSince databases are commonly used to store private data, such as authentication information, personal user data and site content, if an attacker gains access to it, the consequences are typically very severe, ranging from defacement of the web application to users data leakage or loss, or even full control of the web application or database server.\",\n         },\n         \"url\":\"http://test-site.example.com/login.php\",\n         \"path\":\"login.php\",\n         \"method\":\"post\",\n         \"parameter\":\"username\",\n         \"value\":\"\",\n         \"params\":{\n            \"username\":[\n               \"probely'\"\n            ],\n            \"password\":[\n               \"probely\"\n            ]\n         },\n         \"reporter\":\n          \"(...)\"\n         ,\n         \"assignee\":null,\n         \"state\":\"notfixed\",\n         \"severity\":30,\n         \"last_found\":\"2017-08-01T14:03:56.207794Z\",\n         \"changed\":\"2017-08-01T14:03:56.207794Z\",\n         \"changed_by\":\n          \"(...)\"\n         ,\n         \"comment\":\"\"\n      },\n      \"(...)\"\n   ]\n}\n```\n\nYou can also view all the target findings, which will show all the findings\nthat are not yet fixed. \\\\\nThe structure is similar to the previous result.\n\n```bash\ncurl https://api.probely.com/targets/AxtkqTE0v3E-/findings/ \\\n  -X GET \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: JWT PROBELY_AUTH_TOKEN\"\n```\n\n\n### Get vulnerability details\n\nYou can also get details for a particular finding in a target. \\\\\nIn this example we will get the details for the same finding as in the previous\nsection:\n\n```bash\ncurl https://api.probely.com/targets/AxtkqTE0v3E-/findings/79/ \\\n  -X GET \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: JWT PROBELY_AUTH_TOKEN\"\n```\n\n\nThis will result on the same information, but just for this particular finding:\n\n```json\n{\n   \"id\":79,\n   \"target\":\n    \"(...)\"\n   ,\n   \"scans\":\n    \"(...)\"\n   ,\n   \"labels\":\n    \"(...)\"\n   ,\n   \"fix\":\"To fix an SQL Injection in PHP, you should use Prepared Statements. Prepared Statements can be thought of as a kind of compiled template for the SQL that an application wants to run, that can be customized using variable parameters.\\n\\nPHP's PDO extension supports Prepared Statements, so that's probably your best option.\\n\\nIn the example below you can see the use of prepared statements. Variables ```$username``` and ```$hashedPassword``` come from user input.\\n\\n```\\n$stmt = $dbg->prepare(\\\"SELECT id, name FROM users\\n                       WHERE username=? AND password=?\\\");\\n$stmt->bindParam(1, $username);\\n$stmt->bindParam(2, $hashedPassword);\\nif ($stmt->execute()) {\\n\\t$user = $stmt->fetch();\\n\\tif ($user) {\\n\\t\\t$_SESSION['authID'] = $user['id'];\\n\\t\\techo \\\"Hello \\\" . $user['name'];\\n\\t} else {\\n\\t\\techo \\\"Invalid Login\\\";\\n\\t}\\n}\\n```  \\n\\nAs an added bonus, if you're executing the same query several times, then it'll be even faster than when you're not using prepared statements. This is because when using prepared statements, the query needs to be parsed (prepared) only once, but can be executed multiple times with the same or different parameters. \\n\",\n   \"requests\":[\n      {\n         \"request\":\"(...)\",\n         \"response\":\"(...)\"\n      },\n      {\n         \"request\":\"(...)\",\n         \"response\":\"(...)\"\n      }\n   ],\n   \"evidence\":null,\n   \"extra\":\"\",\n   \"definition\":{\n      \"id\":\"xnV8PJVmSoLS\",\n      \"name\":\"SQL Injection\",\n      \"desc\":\"SQL Injections are the most common form of injections because SQL databases are very popular in dynamic web applications. This vulnerability allows an attacker to tamper existing SQL queries performed by the web application. Depending on the queries, the attacker might be able to access, modify or even destroy data from the database.\\n\\nSince databases are commonly used to store private data, such as authentication information, personal user data and site content, if an attacker gains access to it, the consequences are typically very severe, ranging from defacement of the web application to users data leakage or loss, or even full control of the web application or database server.\",\n   },\n   \"url\":\"http://test-site.example.com/login.php\",\n   \"path\":\"login.php\",\n   \"method\":\"post\",\n   \"parameter\":\"username\",\n   \"value\":\"\",\n   \"params\":{\n      \"username\":[\n         \"probely'\"\n      ],\n      \"password\":[\n         \"probely\"\n      ]\n   },\n   \"reporter\":\n    \"(...)\"\n   ,\n   \"assignee\":null,\n   \"state\":\"notfixed\",\n   \"severity\":30,\n   \"last_found\":\"2017-08-01T14:03:56.207794Z\",\n   \"changed\":\"2017-08-01T14:03:56.207794Z\",\n   \"changed_by\":\n    \"(...)\"\n   ,\n   \"comment\":\"\"\n}\n```\n\n## Concepts\n\nThe short version is that you run *scans* on *targets*, and *findings* are\ncreated for any issue that is found.\nHowever, there are a few more concepts that must be explained in order to\nget a complete picture of how Probely works.\nWe will spend the next few sections detailing the most important concepts.\n\n\n### Target\n\nA *target* defines the scope of a scan, what will and won't be included\nin the scan plan.\nThis is done by filling a *target*'s *site* and *assets*.\n\nThe entry point for the web application (and authentication) is setup\nin the *target*'s *site*.\n\nIn modern web applications, you are probably loading resources from\nmultiple domains.\nA single page app, for example, will usualy load the page from one domain\nand make AJAX requests to another.\nThis is what *assets* are for: they specify what domains our scanner should\nfollow and create requests for.\n\n\n### Site\nA URL is probably not the only thing you will need to setup when scannning your application.\nDoes the application have an authenticated area? Does it use basic auth?\nDoes it expect a certain cookie or header?\nThese parameters are all configured in the *target*'s *site*.\n\n\nWe need to ensure that only allowed web applications are scanned.\nTherefore, we must verify that you have control of any site you wish to include.\nThis can be done by:\n  * Placing a file on a well-known location, on the site's server;\n  * Creating specific DNS records.\n\n\n### Asset\n\nAn *asset* is very similar to a *site*. The difference is that it is a domain instead\nof a URL. Additionally, an *asset* has no login or basic auth support.\nYou can still have custom cookies and headers per *asset*.\n\nAs with the *site*, you will need to prove an *asset*'s ownership. We have added some\nrules to make your life easier, if you already have verified\na *site* and the domains match, the validation is fast-tracked.\n\n### Scans\n\nThis is what you're here for.\nAfter configuring your *target*, you will want to run *scans* against it.\nYou can either start a one off scan, or schedule one for later - recurring\nor not.\n\nDuring the *scan*, we will spider and run several modules to check for\nsecurity issues, which we call *findings*.\nYou can check the *findings* even before a scan ends.\nIf everything goes well, the scan will complete and that is it.\n\nWith some *findings*, our automated processes may have difficulties\ndetermining if it is a false positive or a legitimate issue.\nIn these instances, a scan will be marked as under review, and we will\nfurther analyze the finding before making a decision.\nWe will only show findings that, for some degree of confidence, are true\npositives.\nA finding that we are not sure of will never be displayed.\n\nAs much as we try to prevent it, a *scan* (or a sub-module) can malfunction.\nIf this happens, a *scan* is marked as:\n  * \"failed\": the problem was irrecoverable;\n  * \"completed with errors\": some module failed but the scan itself completed.\n\nDuring a scan, we try to determine what *frameworks* you are using\nand add this information to the *site* and *asset* objects discussed\npreviously.\n\n\n### Findings\n\nThe last core concept is the *finding*, this is a security issue that\nwe have found during our scans.\nIf the same issue is found in a new scan it will not open a new finding but\nupdate the previous.\n\nA *finding* will have a lot of information about the issue.\nNamely, where it was found, URL, insertion point (e.g. cookie), parameter,\nand method.\nEvidence we gathered, and the full request and response that we used.\nSugestions of how to go about fixing it.\nA full description of the vulnerability is also present in the\n*definition* property.\nWe also assign a severity and calculate the CVSS score for each.\n\nBesides all this, there are also actions that you can perform on a *finding*.\nYou can assign it to one user, leave comments for your team or add labels,\nand reduce or increase the severity.\n\nIf you don't plan on fixing the *finding* and accept the risk, or you think\nwe reported a false positive, you can mark the finding to reflect that.\n",
    "title": "Probely Developers",
    "version": "1.2.0",
    "x-apisguru-categories": [
      "monitoring"
    ],
    "x-logo": {
      "altText": "Probely",
      "url": "https://api.apis.guru/v2/cache/logo/https_developers.probely.com_assets_logo_dark.png"
    },
    "x-origin": [
      {
        "format": "openapi",
        "url": "https://developers.probely.com/openapi.yaml",
        "version": "3.0"
      }
    ],
    "x-providerName": "probely.com"
  },
  "updated": "2021-07-19T09:27:57.385Z",
  "swaggerUrl": "https://api.apis.guru/v2/specs/probely.com/1.2.0/openapi.json",
  "swaggerYamlUrl": "https://api.apis.guru/v2/specs/probely.com/1.2.0/openapi.yaml",
  "openapiVer": "3.0.0",
  "link": "https://api.apis.guru/v2/specs/probely.com/1.2.0.json"
}