DEV Community: Mark Foppen

Blazor WebAssembly with Azure Active Directory and Azure Functions

Mark Foppen — Thu, 02 Apr 2020 09:19:34 +0000

Since the newest Blazor WebAssembly version we have to possibility to use MSAL to authenticate with Azure AD and other OpenID Connect providers. In this post I will focus on authentication with Azure AD. For this I created a repository on github.

This solution will allow you to authenticate and make calls to an Azure function with Blazor WebAssembly.The Azure function and Blazor app will be Azure Active Directory protected.

Prerequisites

Use the latest Blazor preview installed 3.2.0-preview3.20168.3. See here for more info.

Getting Started

First, we need to create an app registration in your Azure Active Directory. You can do this by going to https://portal.azure.com for the Tenant you want to deploy your app in. Create an application like below. Set the redirect URL to localhost so that you can use it on your local machine.

After your registration is completed it should look like this:

Go to the "Expose Api" page and set the Application ID URI to API://clientid. My client id in this case is ddc79846-0ed0-4347-a997-dc10bcf58e48. After this, you also need to set the scope. Set this to API://clientid/user_impersonation and Save.

Now, let's go to the Authentication page and change the URLs to match the ones below. Als make sure to check the Access Tokens and ID tokens checkbox. If you haven't already done so make the app multi-tenant at the bottom.

Azure function config

I am not going in-depth on how to deploy an Azure function and will go straight to the configuration. Before we do that we need to take 2 things from the application registration we just configured

Client ID
Client Secret (Generate one in the Certificates & Secrets page)

After you have copied these go to your azure function and go to the new still in preview portal of Azure functions. Go to the Authentication/Authorization page.

Do 3 things here:

Switch App Service Authentication to On
Set Action to take when a request is not authenticated to Log in with Azure Active Directory
Click the Azure Active Directory row

The second to last step is to set the Active Directory Authentication to advanced and paste you two values we copied earlier.

This should be enough to get it working. Still, if you want to make sure it works on your local machine we have one more setting to go.

Go to the cors page of azure functions and set an extra cors rule to your localhost environment as I did:

Configure the Solution

For you to be able to run this solution there are a few settings that need to be done. Open the solution (or folder if you are in vs code) and edit the appsettings.json file in the Web project. Set your own clientId and API backend. This can be the Azure function we just configured or a localhost function. Do note that on your local machine you can not test the AD authentication.

{
  "clientId": "ddc79846-0ed0-4347-a997-dc10bcf58e48",
  "postLogoutUrl": "https://localhost:5001",
  "apiBackend": "https://<your azure functionn>.azurewebsites.net/api/" // or "https://localhost:7071/api"
}

That is it. If something is not working for you, feel free to create an issue on the github repository.

Azure AD Application Registration Security with Graph API

Mark Foppen — Fri, 04 Oct 2019 15:53:45 +0000

In many Azure Active Directories, there are registered applications. These applications all have security permissions. Do you know which one has which permissions and can access what data and resources? Do you know who has the secrets that give access to this data? Let's take a look at how we can achieve this.

In this blog, I will show you how to generate a list of applications and the permissions they have by using the beta version of the Microsoft Graph API. This will allow you to act on them. It is fine if some applications have a high permission level. At least after reading this blog you have the change retrieve them and to make sure the owners of the applications guard the secrets the best they can. Let's dive right into retrieving the applications.

Don't know what Azure Active Directory Application registrations are? Check out this earlier blog post. If you wanna know more about the Microsoft Graph API beta you can see this blog on how to connect to it.

Setup app registration with permissions

Before we can retrieve the applications from the Graph API, we need to authenticate it to the Azure Active Directory. This is done by adding an application registration. Yes, this is the same type of application we are trying to retrieve. In this case we are need to create a application registration with Directory.Read.All permission.

To create an application you can go to my GitHub here. There is a detailed guide in the readme on how to set this up.

After you are done retrieving the applications, make sure to disable or delete this application.

Now that you have created the application, you can get an access token. We do this in C# by using the MSAL library (Microsoft.Identity.Client). This allows you to generate the token we use later in this blog.

var ccab = ConfidentialClientApplicationBuilder
    .Create(clientId)
    .WithClientSecret(clientSecret)
    .WithTenantId(tenantId)
    .Build();

var tokenResult = ccab.AcquireTokenForClient(new List<string> { "https://graph.microsoft.com/.default" });
var token = await tokenResult.ExecuteAsync();
return token.AccessToken;

The token we just retrieved is a JWT token that permits us to access the Graph API. Specifically in this case to retrieve the applications from an Azure tenant.

If you ever wonder what permissions are associated with the current token. Go to https://jwt.io/ and paste in your token.

Retrieve Applications

To retrieve the applications we use the previous access token and make a GET call to https://graph.microsoft.com/beta/applications. Notice that we make use of the beta version of the Graph API.

Below is the C# code:

using (var request = new HttpRequestMessage(HttpMethod.Get, "https://graph.microsoft.com/beta/applications"))
{
    request.Headers.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
    request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", "<Your Access Token Here>");

    using (var client = new HttpClient())
    using (var response = await client.SendAsync(request))
    {
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }
}

Executing this code will return all the applications from the tenant.

Each call to the Graph API will result in a maximum of 100 results. If there are more results, there will be a nextlink property with a URL to retrieve the next 100 results.

Below is an example of the JSON returned. I removed a lot of empty properties in this case. As you can see we have retrieved an application but the only readable data is the display name. What API's is this app giving permissions to? What permissions are assigned? Are these delegated or application permissions?

{
    "id": "1deb4abb-fea2-401b-8881-0bf7f86dda12",
    "appId": "092424f2-09ba-49fb-bfd1-f4fd9c352e82",
    "createdDateTime": "2019-08-10T21:08:51Z",
    "displayName": "Data Engine",
    "appRoles": [],
    "keyCredentials": [],
    "passwordCredentials": [],
    "requiredResourceAccess": [
        {
            "resourceAppId": "00000003-0000-0000-c000-000000000000",
            "resourceAccess": [
                {
                    "id": "465a38f9-76ea-45b9-9f34-9e8b0d4b0b42",
                    "type": "Scope"
                },
                {
                    "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
                    "type": "Scope"
                },
                {
                    "id": "df021288-bdef-4463-88db-98f22de89214",
                    "type": "Role"
                }
            ]
        }
    ]
}

To make sense of al these guids we need to retrieve some extra data. By retrieving the service principle of each API we can link the guids to some actual text.

Retrieve service principles

First, let's retrieve the service principles in the Azure tenant. We are doing the same call as before with a slight difference in the URL. Instead of calling the /application we now call /servicePrincipals?filter=appId eq '00000003-0000-0000-c000-000000000000'. This will retrieve the associated API.

using (var request = new HttpRequestMessage(HttpMethod.Get, "/servicePrincipals?filter=appId eq '00000003-0000-0000-c000-000000000000'"))
{
    request.Headers.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
    request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", _accessToken);

    using (var client = new HttpClient())
    using (var response = await client.SendAsync(request))
    {
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }
}

As you can see below it will return the information about the Microsoft Graph. Also for this response, I deleted a lot of properties to make it a little more readable.

{
    "id": "9a1be802-1792-48de-92e4-ea67cb2ec6e9",
    "appDisplayName": "Microsoft Graph",
    "appId": "00000003-0000-0000-c000-000000000000",
    "displayName": "Microsoft Graph",
    "publishedPermissionScopes": [
        {
            "adminConsentDescription": "Allows the app to read events in user calendars . ",
            "adminConsentDisplayName": "Read user calendars ",
            "id": "465a38f9-76ea-45b9-9f34-9e8b0d4b0b42",
            "isEnabled": true,
            "type": "User",
            "userConsentDescription": "Allows the app to read events in your calendars. ",
            "userConsentDisplayName": "Read your calendars ",
            "value": "Calendars.Read"
        },
        {
            "adminConsentDescription": "Allows users to sign-in to the app, and allows the app to read the profile of signed-in users. It also allows the app to read basic company information of signed-in users.",
            "adminConsentDisplayName": "Sign in and read user profile",
            "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
            "isEnabled": true,
            "type": "User",
            "userConsentDescription": "Allows you to sign in to the app with your organizational account and let the app read your profile. It also allows the app to read basic company information.",
            "userConsentDisplayName": "Sign you in and read your profile",
            "value": "User.Read"
        }
    ],
    "publisherName": "Microsoft Services",
    "appRoles": [
        {
            "allowedMemberTypes": [
                "Application"
            ],
            "description": "Allows the app to read user profiles without a signed in user.",
            "displayName": "Read all users' full profiles",
            "id": "df021288-bdef-4463-88db-98f22de89214",
            "isEnabled": true,
            "origin": "Application",
            "value": "User.Read.All"
        }
    ]
}

In the JSON result above you can also see that there are published permission scopes and approles. published permissions scopes are your delegated permissions and the approles are your application permissions. As you can see there is a lot of human-readable text instead of guids. Below is a simple overview of how each property links to another.

Now that we have retrieved the application we also want to know who the owner is. In case we have questions or for governance purposes, you want to know who owns the applications.

Retrieve the owners

Retrieving the owners is again the same principle as the other calls. By supplying your app id in the URL you can retrieve the owners of that specific app. It can return multiple results.

using (var request = new HttpRequestMessage(HttpMethod.Get, $"/applications/{AppId}/owners"))
{
    request.Headers.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
    request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", _accessToken);

    using (var client = new HttpClient())
    using (var response = await client.SendAsync(request))
    {
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }
}

When the call is executed you will receive a JSON response similar to this

{
    "@odata.type": "#microsoft.graph.user",
    "displayName": "Mark Foppen",
    "jobTitle": "Developer",
    "userPrincipalName": "test@re-mark-able.net"
}

Output wrapped in web application

Now you know how to retrieve the applications from you Azure tenant, link all the properties together and retrieve the owners, it is time to make it a little more visible then JSON output. To do this I created a simple web app that shows the output of the call for your specific tenant. The source code can be downloaded from my GitHub here

Making it more secure

Now we know what applications we have and what permissions are assigned. We also retrieved who the owner is. Now it's up to you to at least retrieve all the applications from your tenant and put some sort of governance on them. Of course, it is okay to keep applications that have permission to access data but now you can at least compare en react on it. Contact the owners to check if the app is still used and discuss why those permissions are needed.

Thanks for reading and keep pushing to make things more secure!

Sending your Threat Indicators to Azure Sentinel

Mark Foppen — Sun, 18 Aug 2019 22:14:00 +0000

How and why should you send your threat indicators to Azure Sentinel or add them manually to the Microsoft Defender Advanced Threat Protection (MDATP) solution? What is an indicator, also known as an Indicator of Compromise (IoC)? Why should you care? How can you do this? Let's go through this and add indicators manually and by using a Logic App and the Microsoft Graph Security API.

First, we will take a look into what an Indicator is and how it works in MDATP to get a better understanding of what we are dealing with. Then send the indicator to Azure Sentinel through the Microsoft Graph Security API.

What is an indicator?

An IoC is a piece of evidence that could indicate you have malicious activity in your environment. This can have many forms i.e.:

File hashes
Network activities
Ip address or URL's

The IoC on its own doesn't necessarily mean you have been compromised. Often the combination of file hashes, network activity, and origin (IP or Url) are the providers of context which in turn determines if it is a threat. For more info, you can have a look at the Mitre ATT&CK framework here. This is a framework to describe what tactics and techniques are used to identify and defend against attacks on your organization.

This is all good and fine but what if you encounter an application on one of your managed devices and want to block it for the entire organization? Take for example an Android application (.apk) that is not detected by MDATP at the moment. As we all know these applications can also have malware in them or download other applications. One of your users sends it to another and another and so forth. How can you stop this? By adding the file hash of the APK to the indicators in MDATP. This will stop the spreading of the file and allow you to further investigate it.

Add an indicator manually

Let's go to the MDATP portal and sign in. To get to the Indicators page we first have to go to Settings in the left menu and then to the indicators page. Here you have an overview of all your indicators. This should look like the portal below

By clicking on +Add Indicator we can add a new indicator manually. Here you must give the file hash which can be a SHA1, SHA256 or MD5. For now, there is a limit of 5000 indicators at the time of writing this post. By setting the expiration date you automatically clean them up.

When you go to the next step in adding an indicator you must determine the actions MDATP should take when there is a file with the same hash. We have 3 possible actions:

Allow
Alert Only
Alert and Block

Allow is used when MDATP is already blocking a file or executable that you do not want to be blocked. Take for example Mimikatz, if you put the file hash of that in here you can use the program without MDATP putting it in quarantine.

Alert Only is used when you only want to receive an alert that the file is detected but not want to block it. If you can post the Alert yourself you should not be using this. Instead use the MDATP API (docs here) to create the alert. This way you won't be using another spot on that 5000 entries limit.

Alert & Block is used when you immediately want to block the file on all or scope of machines. Be very careful with this option. If a critical windows file ends up here it will have an impact on your organization.

The 3rd and last page is to set the scope of the indicator. In the screenshot below you don't see any scope since I don't have any. The scope can be set to a determined list of machines or all machines in the organization.

The last step is the summary to make sure you didn't make a mistake and double-check your input.

After we completed these simple steps you will see the indicator added to the list.

Add Indicators through the Microsoft Graph Security API

Now that we have a good understanding of what threat indicators are and how they are working, we can start adding them to Azure Sentinel. Why would we want to add them to Azure Sentinel? Azure Sentinel is a very good product to correlate security events across different log sources and different Microsoft security products.

Make sure that the Threat Intelligence data connector in Azure Sentinel is enabled.

To add the indicators to Azure we are using the Microsoft Graph Security API (beta). Before we post a new indicator we need to set some properties first:

Action: Alert, only give an alert, do not block the file.
FileHashType: SHA256, in this example we only process SHA256 hashes to keep it simple
FileHashValue: The actual file hash
ExpirationDate: When will the indicator expire

A basic post message would look something like this:

{
  "action": "alert",
  "activityGroupNames": [],
  "confidence": 0,
  "description": "This is a canary indicator for demo purpose. Take no action on any observables set in this indicator.",
  "expirationDateTime": "2019-03-01T21:44:03.1668987+00:00",
  "externalId": "Test--8586509942423126760MS164-0",
  "fileHashType": "sha256",
  "fileHashValue": "b555c45c5b1b01304217e72118d6ca1b14b7013644a078273cea27bbdc1cf9d5",
  "killChain": [],
  "malwareFamilyNames": [],
  "severity": 3,
  "tags": [],
  "targetProduct": "Azure Sentinel",
  "threatType": "WatchList",
  "tlpLevel": "green",
}

To keep it simple you can either post this to the Graph Security API with postman or by using an Azure Logic App as I did. Your Logic App Http step will look similar to below:

In the logic app, you see a client id and client secret. These are from the application registration and you can have a look here how you can set that up. Keep in mind that your application needs the permission ThreatIndicators.ReadWrite.OwnedBy for the request to work. This permission needs to be granted by a global administrator in your tenant.

Did you notice the targetProduct property set to Azure Sentinel? This is what specifies where the indicator is redirected to.

After a successful post, you can view the indicator in the Azure Sentinel dashboard. This can be done by going to the ThreatIntelligenceIndicator log source

When you query this you will get something similar like below, depending on how many indicators you posted.

It is re[mark]able how easy it is to add indicators to MDATP and Azure Sentinel, but yet so powerful. Now you can leverage the data of indicators in Azure Sentinel alerting, correlation and hunting.

Thanks for reading!

Using Microsoft Defender ATP Streaming API with Misp

Mark Foppen — Tue, 23 Jul 2019 15:07:21 +0000

Would it not be great if you can access all the data from the new Microsoft Defender Advanced Threat Protection (MDATP)? It would be great if you can just access all that data through an API. But I really do not want to develop another polling mechanism to pull in all the data. That is where the new MDATP Streaming API comes in which just got enabled for public preview.

In this post, you will see how easy it is to configure the new Streaming API and how you can get access to the data. You will see how the new API can be attached to Azure Storage and Azure Event Hub.

Once we receive all the data we can check file hashes in a 3rd party threat intelligence provider like MISP. First, let's configure the MDATP streaming API.

Configure MDATP Streaming

We start by going to the MDATP portal here where you will see the default dashboard. To start configuring you need to go to the Data Export Settings page.

In this page, you can add a total of 5 streaming connections. At the moment there are two types of Azure resources you can connect to:

Azure Storage
Event Hub

If you choose for the Azure Storage option then the MDATP stream will save all the events in a *.json file as blobs.

On each connection you can choose between 9 types of events:

AlertEvents
MachineInfo
MachineNetworkInfo
ProcessCreationEvents
NetworkCommunicationEvents
FileCreationEvents
RegistryEvents
LogonEvents
ImageLoadEvents
MiscEvents

For now, I am only going to focus on the connection between an Event Hub and MDATP for the FileCreationEvents. If you want to make sure that you catch all of the files and processes on every device you should also add the ProcessCreationEvents.

When you add a new connection you will get all the options I just mentioned. You can make a choice here and configure the connection how you like. I am going to configure it for an event hub to only receive file creation events from MDATP.

Now that the Event hub is configured the data should start coming in and it will look something like this

Tip : Only enable the types of events you really want to have since the volume of messages can be very high. This is not an issue for Event Hub but could be very costly if you connect it to a logic app where you pay per execution.

For example 'NetworkCommunicationEvents' logs every connection made on every machine. I had to learn the hard way by wasting my entire worth of monthly Azure credits ($150) in 2 days because it was connected to a Logic app :| ...

As you can see below most of the costs are in the connection and the executed actions for the logic app and not in the Event Hub. So be cautious as to what you connect to the Event Hub. The high event hub costs are due to the enabled 'Capture' feature and the standard tier. Not because of the number of events.

This however triggered me to look into the actual costs of using the MDATP streaming API with Event Hub. To do that we first need to know how many events are sent. I created a new Event Hub namespace, connected it to MDATP streaming API and selected all available events. The next 24h I let it run to capture all the events. To give some context to this I have counted all the different types of events and the number of machines in my tenant.

NetworkCommunicationEvents: 95,070

ImageLoadEvents: 23,091

MiscEvents: 57,444

ProcessCreationEvents: 24,795

RegistryEvents: 49,191

MachineInfo: 2,213

MachineNetworkInfo: 10,712

FileCreationEvents: 39,487

LogonEvents: 1,982

AlertEvents: 4

This leaves us with a total of 303.989 events on 83 different machines. The average size of one event is ~2.47 kilo byte and one machine gives ~3,662 events per day. On monthly costs, this would mean you have ~9 million events which will cost you around $0.25.

Consuming Eventhub with a Logic app

Sometimes there are use cases that require a third-party threat intelligence system to check for malware. For example, to detect Android APK's with malware in them. A good example you can see here. For this example, we will be using MISP also know as a Malware Information Sharing Platform and Threat Sharing. This is a free and community-driven threat intelligence platform. In this post, we will not cover how to set this up but you can see how this can be done on Kali Linux here

Here is a list of goals we want to achieve:

Read the events from the event hub
Check the file hashes against Misp
Add the indicator to MDATP

Do note that this is an implementation in the most basic form you can think off without any error handling or what so ever. Let's take a look at the Logic App overview

First we receive the events through the Event Hub Logic App trigger which is connected to the MDATPStream hub as shown before. When you save the Logic App with only the trigger you will get a response like this:

Now that we receive events we can call the Misp API with the following parameters to check if that file is known as a possible indicator of compromise (IoC).

After this, we parse the response and check if there are any IoC's returned from Misp. If that is the case we have found a match. At this point, it is up to you what you do with this detection. The first thing you could do i.e. is, Posting an Alert directly to MDATP with the Windows Defender Advanced Threat Protection (WDATP) logic app connector.

The way to achieve alerting of the found IoC is through creating an alert with the WDATP connector. You can do this by adding it to your logic app and connect it with a global admin account.

To create an alert, you need to set the machine id which can be found in the event hub message. For the other fields, you can set them as you like. To give meaning to the alert, you should call the Misp once again and retrieve the event from Misp. An event in Misp gives context to the found IoC and therefore also contains fields like title, severity, comments, etc.

Possibilities?

Although this post only describes one possible implementation of the MDATP streaming API there a lot more possibilities. To name a few:

Save the MDATP data to a separate storage to retain it indefinitely
Instead of polling your MDATP alerts from the graph API you can now respond to the alerts real-time
Monitor network communication real-time
Stream your data to a 3rd party that is handling your security
Stream all the evens into your Security Information and Event Management (SIEM) solution
Add your data to Azure Sentinel, since there is no connector yet.

And a few others, just for fun or because you can

Draw a world map and show all the unlock and logins in real-time by processing LogonEvents
Respond to people that they shouldn't work during their holidays by using the LogonEvents, ProcessCreation en FileCreationEvents ;)

It is re[mark]able how much data is inside the MDATP product and for now we only scratched the surface. This should give you a good indication of what is possible in real-time with the MDATP streaming API.

Thanks for reading!

How to access data from the beta channel of Graph API

Mark Foppen — Mon, 08 Jul 2019 19:59:59 +0000

All the new features of the Microsoft Graph API are first available in the beta version. By using the beta version you can get early access to new features. Microsoft often adds new features as can be seen on their GitHub changelog here.

In this post we will do three things:

Create an Azure Active Directory application registration
Get the access token through the registered application
Call the Graph API on the beta version

This is all done by using the Azure portal and implementing the code to call the Graph API in C#.

Adding an Application to your Azure Active Directory

To get access to the Graph API we need to register an application in the Azure Active Directory (AAD). This application can be used to add permissions. An administrator of that AAD can then consent to the permissions selected by you. Let's go through this step by step.

Open the Azure portal and go to the AAD that you want to add the application to. Now you can add the new application like this

When the application registration is created you can see 2 important id's we need in a later stage. This is the Application (client) Id and the Directory (tenant) Id.

Next step is to add permissions to the application registration. These permissions give the application the ability to access resources. In our case, this is the Graph API. Let's add the Directory.Read.All which gives us permission to read everything within this AAD but not change it.

As you might have seen there are 2 types of permissions:

Delegated Permissions - These permissions are used when there is a signed-in user. Typically used for portals or Azure functions that have AD authentication.
Application Permissions - Should only be used on background services. These permissions can only be granted by an administrator.

Now that the application registration has the permission we want, it is still not granted. To grant this permission on this AD we need an administrator account to give consent. This can be done on the 'API Permissions' page where we just added the new permission.

After giving consent to the permission there is only one thing left to do and that is adding a secret to the application. This is basically the same as a password that gives you access to use the application. Only in this case, you can have multiple secrets with each a different expiry time. You can also delete these secrets. To add a secret we need to go to the "Certificates & secret page".

Do keep in mind that you can only see the secret once. Now that we finished this we have the following data that we need to use in the next step:

Tenant id: '5d1821a3-a004-4cc0-95d5-cb2e797ceaf1'

App Id or Client Id: '42903c50-6fc9-40db-a131-87f4522dcf56'

App Secret or Client Secret: 'fe_?xg+VhSxe_iq4RSw9TE4AUlddktg8'

We only created an app registration for a single tenant with default settings mostly. If you want more detailed information on i.e. a multi-tenant application you can go to the Microsoft docs here.

Get the access token

In order to access the Graph API, we first need to acquire an access token. This token can be used as a bearer authorization header later on. To do this I used the NuGet package Microsoft.Identity.Client version 4.0.

private async Task<string> GetAccessToken(
    string tenantId,
    string clientId,
    string clientSecret)
{
    var builder = ConfidentialClientApplicationBuilder
        .Create(clientId)
        .WithClientSecret(clientSecret)
        .WithTenantId(tenantId)
        .WithRedirectUri("http://localhost/")
        .Build();

    var acquiredTokenResult = builder.AcquireTokenForClient(
        // Here we set the scope to https://graph.microsoft.com/.default
        new List<string> { "https://graph.microsoft.com/.default" });
    var tokenResult = await acquiredTokenResult.ExecuteAsync();
    return tokenResult.AccessToken;
}

Call the Graph API

Normally you would just use the Graph API client SDK which is the NuGet Microsoft.Graph but even the preview versions do not have all the available calls. Therefore I am not using this NuGet. Instead by using a simple HttpClient we can achieve the same.

The code below will do the following:

Retrieve the access token
Set the version to beta
Set the endpoint and the action we want to execute
Create the HTTP client
Set the headers including the authorization bearer header
Sending the request which actually is an HTTP get
Read the result as a string, since the response will be in JSON format

private async Task CallGraphApiBetaChannel()
{
    // Retrieve the access token
    var accessToken = await GetAccessToken(
        "5d1821a3-a004-4cc0-95d5-cb2e797ceaf1",
        "42903c50-6fc9-40db-a131-87f4522dcf56",
        "fe_?xg+VhSxe_iq4RSw9TE4AUlddktg8");

    // Set the version to beta
    var graphApiVersion = "beta"; // 'beta' or 'v1.0'

    // Set the endpoint and the action we want to execute
    var endpoint = $"https://graph.microsoft.com/{graphApiVersion}";
    var action = "/applications";

    // Create the http client
    using (var client = new HttpClient())
    using (var request = new HttpRequestMessage(HttpMethod.Get, endpoint + action))
    {
        // Set the headers including the authorization bearer header
        request.Headers.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
        request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);

        // Sending the request which actually is a http get
        using (var response = await client.SendAsync(request))
        {
            if (response.IsSuccessStatusCode)
            {
                // Read the result as string, since the response will be json
                var result = await response.Content.ReadAsStringAsync();
                // Do something with the result
            }
        }
    }
}

After you get the results you can parse the response how you like. Do keep in mind that if you generate a class model from the JSON it can be broken at any moment since they regularly push updates to the beta.

If all went right you should be able to retrieve all the available applications in your Azure Active Directory. It is in my opinion re[mark]ably easy to use this and you can change the action variable to any method you can find in the beta reference docs here. Also by using this, you have control over how to parse the responses.

Thanks for reading!

Azure Sentinel: Taking Security To The Next Level

Mark Foppen — Fri, 03 May 2019 08:15:00 +0000

Just before the RSA 2019 conference, Microsoft announced a new cloud-native SIEM solution called Azure Sentinel. Sentinel is meant to be the extra pair of eyes to keep your enterprise even more secure than before. Threats are more eminent than ever before since more and more companies go to the cloud. Therefore, attackers have more ways to breach your cloud environment. To counter this you can use Sentinel that enables you to ‘Collect’ data across all your users, applications and resources both on-premise and in the cloud. By using Sentinel you can ‘Detect’ threats using predefined use cases like any other SIEM or by using the build in AI. ‘Investigate’ and rapidly respond to threats manually or automatically.

Why is this the next step?

Currently, there are a lot of different security providers and products within the Microsoft cloud. Think of Azure Security Center or Windows Defender Advanced Threat protection. When one of the security solutions detect a possible malicious activity a SecOps employee has to take a look at what is happening. The employee would then determine what type of alert it is and login into the specific solution portal. For Windows Defender ATP that would look something like below, where in this case the mimikatz tool was downloaded and extracted before windows defender on the specific machine could intervene.

What we miss here is all the information that other security solutions could have caught on possibly the same activity. Like how did it get downloaded in the first place (patient zero)? To solve this there should be one central place to get an overview of the entire malicious activity. This is where Sentinel comes in.

With Sentinel, you have a far more advanced overview (at time of writing not in public preview yet) of the activity. This would reduce the time spent on figuring out what is happening and instead is spend on solving it and making the affected customer safer.

How can Azure Sentinel help?

The majority of the CISO who run a SOC (Security Operation Center) to monitor their On-premise IT are hesitant to move to the cloud. In the past, there was a lack of controls to monitor the cloud IT and this sentiment has stuck with the majority of the CISO that we meet. Historically the heart of a SOC is its SIEM (Security Information and Event Management) tool. A SIEM is hard to build and takes a lot of maintenance and time from the technical and security staff. Some key issues with an on-premise SIEM are in my opinion:

Hard to set up, there is a steep learning curve and a lot of different data to collect and make sense of.
The need for probes, to get the bigger picture you need to install probes and agents. It takes a long time and a lot of skill to configure these properly;
Often limited to on-premise IT, while IT tens to migrate to the cloud there is a lack of integration of “cloud log-data”;
No machine learning, all logic must come from the SIEM vendor and the data analytics skills of the SecOps team;
Slow updates, the AI of the traditional SIEM is embedded in the vendor’s software so in case of a new attack the SIEM will only learn the detection algorithm after a vendor’s update;
Not easy scalable, the hard and software requirements need to be planned upfront and are not so easy to change and evolve as the business needs;
Expensive to own and operate, to set up and maintain a SIEM there is a need for time and highly skilled SecOps personnel which are both had to come by.

Microsoft reimagined the SIEM tool as a new cloud-native solution called Microsoft Azure Sentinel. Some of the key features of Azure Sentinel are:

easy to collect security data
hybrid IT organization
devices
users
apps
servers on any cloud

Sentinel integrates with all Microsoft (Security) alerts and logging and collaborates with many partners in the Microsoft Intelligent Security Association.

Eliminating the need to spend time on:

setting up
maintaining
scaling infrastructure

Sentinel is already integrated into the Azure portal and comes with build in connectors. All scaling and maintenance (patching) is done automatically.

Azure Sentinel

Intelligent security analytics at cloud scale and speed, as one Azure tenant gets attacked with a new attack Microsoft’s SecOps investigates and builds new AI for Sentinel and the AI of Sentinel is updated as soon as Microsoft releases it to the cloud.
Identifying threats with ML, Azure Sentinel uses state of the art, scalable machine learning algorithms to correlate millions of low-level anomalies to come up with a few high-level security incidents
Supported by opensource detection queries, apart from the ML and IA you can set your own triggers and alerts in Sentinel. This can be done by running custom KQL queries. Microsoft has this GitHub for you to get started and share your own.

With Azure Sentinel there are no upfront costs, you pay for what you use. This way you can have your SOC in the cloud faster with less effort and costs. Microsoft will let you connect your Office365, Azure AD, Syslog, Azure Security Center, and 3rd party data for free so when the organization moves to the cloud with Sentinel you can still rely on your SOC with SIEM, with the added bonus of the power of the cloud.

Taking it to the next level

In addition to everything an ‘ordinary’ SIEM is capable of, with Sentinel you can also enable “Sentinel Fusion”. Fusion is adding artificial intelligence with advanced machine learning models to your alert detection. Okay great! what does this mean and what does it do?

A lot of alerts from the different Microsoft security solutions and providers confront you with low or medium severity detections. With the machine learning models from Sentinel Fusion, you can automatically detect if these ‘not so important’ detections are worth looking into it. The AI will also try to correlate events from different providers through the use of entities. These can be configured in sentinel through something that is called ‘Entity types’. For now, these entities are Account, Host or IP address. As you can see below the use cases you create in Sentinel have the ability to link any column to the appropriate entity type.

Can a Azure Static Website really be this cheap?

Mark Foppen — Sat, 09 Mar 2019 16:52:34 +0000

So why should I change to Azure Static Websites? If this is a lot cheaper there are limitations right? Lets put it to the test.

What is it?

A while ago Microsoft announced the general availability of Azure Static Websites. This means that you can host your website files in a blob storage and host your website from there. You can read all about it here: Microsoft Announcement

What am I doing?

For this test we need an actual website that we are able to load and produce some page views with. I got a free template from Colorlib called Appy. You can browse to it by going to https://azurestaticweb.z6.web.core.windows.net/ or by looking at the demo at Colorlib.

Since I didn't want to invest a lot of time into making a new website I deployed this template just "as is" into my blob storage account. This can be done by simply copying all the files into the blob folder called "$web". It should already be there since it is auto-created after enabling the static web site feature in the storage account. Next up is generating a load on the page.

Lets produce some page views

In order to get a sense about the cost of the way we are hosting, we are going to produce some page views. To do this a setup a simple Selenium test that does the following:

Start a new Firefox window with zero caching
Browse to https://azurestaticweb.z6.web.core.windows.net/
Click on "Blog"
Click on "Contact"

The other menu options will be left out since that are all single page navigation items that produce no load at all. This sequence produces three page views. What we really want to know is how many files are we getting from the blob storage since that. The Firefox network monitor reports that one page view is equal to requesting getting 54 files. Of course, this depends on how your website is built.

After this initial call, I put the selenium test in a loop and let it run for over 3 days in a row.

How is the performance?

All of the above is great but how does this perform on heavier loads? Let's look at the graphs below that I got from application insights.

Number of page views over the last 3 days

Number of transactions on the blob storage over the last 3 days

Avarage load times for the entire page (loaded all the 54 files)

As you may have noticed there is a huge spike in the beginning. This was a typo in my selenium test which caused it to produce 700 page views every minute. While most page views were under 1 second load time, with that many page views it sometimes happened that there was a spike up to 2 seconds.

What can we do to improve this?

From a storage point of view, I think it is re[mark]able how well it can handle all the page views. Especially since this is data that is not cached. We have a couple of options to speed up while keeping the costs low:

Redis Cache
Cloudflare Cache
Azure Blob Storage CDN
Azure Front Door

The first two options seem nice at first but Redis cache starts at 16 dollars/month which kinda defeats the purpose of low-cost hosting. While Cloudflare is free but requires a purchased custom domain.

With the third option, it is possible to replace all your files with versions in the CDN. While I think this is possible to automate it just isn't that straight forward.

The last and in my opinion probably the best option is the Azure Front Door. Although it is still in preview it works really well! The pricing in the preview is 8 cents per GB. For more details, you can have a look here. As you can see in the test results above 20k page views is about 1gb for this template website.

Using Azure Front Door

First you need to create the Azure Front Door resource. While adding the resource there is a configuration step like below

There are three steps:

Frontend URLs
This is the URL your users are browsing to. There is an option to use a custom domain here.

Backend pools
In the backend pools, you can specify the resources where a frontend URL is pointing to. You can add multiple resources in a pool. The load balancer will switch between them. This makes it possible to create multiple storage accounts in different geo regions and the Front Door load balancer will automatically route you to the nearest resource to reduce loading time.

Routing rules
Routing rules are the glue between the frontend URL and the backend pool. The routing rules include lots of settings and one of them is caching. This will reduce the load on your blob storage.

After you did these steps your static website will be available within a few minutes on the new *.azurefd.net domain. For me this was https://azurestaticweb.azurefd.net/. Keep in mind that the Azure Static Website is already pretty fast and that Azure Front Door is just an option to either reduce the load time or to scale your application. For now, let's continue on the Azure Static Website feature.

What are the limitations?

There is no server running your code so it is not possible to:

Install something like Node.js
Deploy your ASP.net web app

What is possible:

Using Html, CSS and Javascript
Use ReactJs or Angular
Use WebAssembly
Using Azure Functions as your server-side / backend

Finally, What does this 20k page views, 1gig transferred and almost 2 million transactions cost?

Well since it is really only the blob storage costs you will see something like this.

Notice that the Application insights is "really expensive" in comparison to the Azure Static Web host. But in all fairness, 3 cents (3.12 cents if dollars) is very cheap! This hosting solution is very cheap while still offering a lot of possibilities. As such you can use Azure Functions as your backend e.g. to connect to a database.

Thanks for reading!

Sending Telegram Messages With Azure Function Proxy and Logic App Custom Connector

Mark Foppen — Sat, 02 Mar 2019 13:53:23 +0000

The other day I was experimenting with new Geofencing feature in Azure Maps. What I was trying to achieve is sending a message to my telegram when I leave my home area. How hard can it be right?

Then I discovered that there is no Logic App connector for Telegram and that their Bot API URL format isn't as straight forward as I would like. This explains why there isn't a connector yet. To solve this I used a Logic App connector to call an Azure Function Proxy. The proxy transforms the call to something the Telegram API would understand. This allowed me to make the connection once and easily send a message from multiple logic apps in that same Azure subscription. And above all, this is a 'no code' solution.

Prerequisites

For this to work, there is a prerequisite to registering a bot with Telegram. This is a simple process which is already explained by Microsoft. Register your bot by using this guide https://docs.microsoft.com/en-us/azure/bot-service/bot-service-channel-connect-telegram?view=azure-bot-service-4.0 or have a bot key ready from a previously registered bot.

Next to the bot registration we also need to retrieve the chat id. This can be done by starting a chat with @get_id_bot. Say anything and it will return your chat id. The @get_id_bot can also be added to groups to retrieve the group id.

Sending a message with Telegram Bot API

After retrieving the bot key and the chat id we should be able to send a message with the bot. This can be done by using the following url and replace the placeholders:

https://api.telegram.org/bot<botKey_here>/sendMessage?text=<text_here>&chat_id=<id_here>

An example would be:

https://api.telegram.org/bot628752025:AAFjS9MR3MubX-RWpxqltVtR5Wju9EoUAAo/sendMessage?text=Hello World&chat_id=123456789

Notice that there is a prefix "bot" in the URL we are calling. This is precisely why only a Logic App connector would not be sufficient. A Logic App Connector does not allow to use the API key from the Authentication Type "API Key" in the path. Only 'Header' and 'Query' are supported at this time. What we can do is make use of an Azure Function Proxy to rewrite the URL from only query string parameters to a valid Telegram Bot API URL. You can test the URL by just pasting it in your browser and you will get your first message from the Telegram Bot.

Azure Function Proxy

To be able to change the URL we need to add a new Azure Function App. I used the consumption plan for this but dedicated plan works as well. I created a function app like this:

After the creation of the function app go to the advanced editor and use the JSON below:

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "telegramtrigger": {
            "matchCondition": {
                "route": "/{operation}",
                "methods": [
                    "GET"
                ]
            },
            "backendUri": "https://api.telegram.org/bot{request.querystring.apikey}/{operation}"
        }
    }
}

"route": "/{operation}" makes this proxy trigger on every call to the base URL that can be found in the proxy overview. The 'backendUri' is the new URL that this proxy will call.

The URL is then changed by adding the bot key in there. The {operation} at the end literally just copies everything that is behind your base URL and paste it in the new 'backendUri'.

Logic App Custom Connector

Next on the list is implementing the Logic App Custom Connector. You can download the custom connector template from https://github.com/foppenm/TelegramLogicAppConnector. Open de JSON file in an editor like VS code and change to following to match your proxy URL:

Now let's create a Logic App Custom Connector and press edit.

After importing the changed JSON from the previous step you only have to press "Update Connector" and you can start using it in your logic apps. Optionally you can pick a color and choose an icon to use for this. This determines how it is presented in the logic apps designer.

Now I am able to send a message to my Telegram when an area change is detected within Azure Maps Geofencing. To achieve this, first add the custom Telegram connector to your Logic App and use your bot key.

Then use the event grid trigger together with the 'Send Message' step from the custom connector to send messages on area updates from Azure Maps.

Conclusion

Was this the best use of a custom connector and a function proxy? Probably not but it sure was fun to figure out what it can do and that it can be quite powerful in some scenarios. What I find re[mark]able is the fact that this is a no code solution. Of course you could just use an azure function with the telegram .net library but for this scenario for just sending simple messages is, in my opinion, a total overkill.

Thanks for reading!

How to develop more secure solutions without the hassle

Mark Foppen — Fri, 04 Jan 2019 10:04:11 +0000

As developers, we are constantly trying to implement our solutions in the best way possible. Often we "forget" to look for the vulnerabilities we introduce without really thinking about it. This can happen under pressure of a superior or simply because you can't know every vulnerability out there.

In order to improve this we want to know what is wrong but (I personally) don't want it to be enforced on every local build we do.. For this to improve I found 2 solutions that work really well without you being bothered all the time.

There are 2 different kinds of solutions we can use:

Live information and tips during your development
Vulnerabilities on added dependencies

Security Code Scan

For the first problem, I wanted to be notified during my development in visual studio en visual studio code. This can be done by installing one of the following:

Visual Studio -> SecurityCodeScan ( preferred! ) and/or DevSkim
Visual Studio Code -> DevSkim

In this post, we will mainly be looking into Security Code Scan. In order to use this, you can get it either by installing the visual studio extension Link or by adding it as a nuget on the project you want to monitor. I have added it as an extension and therefore will get vulnerability warnings on every solution that is open.

After installing, make sure to check the "Enable full solution analysis" in Visual Studio > Tools > Text Editor > C# > Advanced, like in the screenshot below.

By now you will get warnings if something is detected. It can present itself in different ways.

You will also be able to fix it most of the time with the quickfix option.

Last but not least, you can also get an overview of all the warnings in the "Error list" view.

In this view, you also have the ability to open the issue in your browser to get additional information, how to fix it and why this is important. I mean you can always ignore it if you think this is not applicable in the current situation.

Solutions for vulnerabilities can be found at Security Code Scan and it wil look like:

As a second solution, you can also use DevSkim which can be found here but in my opinion, this is less useful and it will produce errors on build time. DevSkim does catch some different possible issues like not secure URLs. Unfortunately, it does not support quick fixes or an explanation of why it is a vulnerability.

Snyk

After I implemented a solution, it works and I am ready to deploy it there is a possibility to check it for used dependencies vulnerabilities. This can be done by using Snyk which has a free tier for developers and unlimited tests (runs to check your solution) for public repositories. Keep in mind that for enterprises there are paid options.

First, you need to register a free account. This will give you access to your Dashboard. Now you have two options. You can configure a public repository or use a local (on your machine) project. The public repositories can be configured by going to the "Integrations" page where you can configure a lot of providers.

In this example we are going to use a local project that is not in any repository since the local project is a little more difficult to setup.

So let's get right to it and install Snyk on your machine. To install Snyk I used npm with the following command

npm install -g snyk

After that you have to authenticate with your account.

snyk auth

Which will open the browser and you can login in with your Snyk account. Now you can use it to test your solution by going to project folder

cd c:\<your solution folder>

In my case, this was a solution with .NET project for an azure function. This is supported but not in the default way. Normally you can just run "sync test" and it will automatically check for a lot of different variations of package files in your current folder (see docs). For .NET projects you need to specify the solution file like this

snyk test --file=MySolution.sln

In the summary of your test, you can already see if there are vulnerabilities

To get it in your dashboard on snyk.io you need to run

snyk monitor --file=MySolution.sln

This will send the data to your Snyk account and you will be able to see it in the dashboard and browse through the found vulnerabilities by severity.

A nice added bonus to this monitoring is that it will keep your packages config and alert you when there are newly found vulnerabilities. This way you will get an email when this happened and you can respond to that. This can be set to check on a daily or weekly base.

Is This Usable?

I can only speak for my self but for me, these two steps are easy to implement in local and ci builds and require no hassle to use. An added bonus is that I can use the warnings to improve the solution but I don't have to. If you want it to take a step further you can always take a look into BinSkim. This tool can analyze your DLL's and Executables for know vulnerabilities.

All in all, I think it is really "remarkable" that all this is free to use while it can have real added value to the solutions we make!

Securing Logic App Http triggers

Mark Foppen — Fri, 14 Dec 2018 14:17:46 +0000

For all developers that are using logic app http triggers, here is a brief solution of how we can secure logic apps a little more.

This is a solution without Azure Api Management or making use of proxies to hide the signature from the url and posting it as a header.

In my case I had a scheduled function app that did some data processing and posted the result to a logic app. For this example we will create a downsized/stripped solution of this. To achieve this we need to create the following things:

A logic app
App registration
A scheduled function app

Let's dive right in and create a simple logic app that only has a http trigger.

After saving the logic app an url will be created and it will look like:

https://prod-41.westeurope.logic.azure.com:443/workflows/1dd2822de5034e543088be263d4dd412/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=0qwAP5sOqZ6aA4As8eGjZipRiLRYOTuwnHuaMjwEMGb

Don't worry, this http trigger isn't live anymore.

Now anyone with this url can trigger the logic app. Therefore it would be wise not to share this or store it.. Wait what? How are you supposed to call it then? We can retrieve the url from the logic app resource. But in order to do that we need to create a app registration first.

App registration

In order to solve this problem we need to create an app registration on the Active Directory (AD) and subscription where your logic app is created. This can be done by going to http://aka.ms/registeredappsprod or by navigating to https://portal.azure.com > Azure Active Directory > App registration. Just create a new one with no permissions. Also the redirect url can be left empty. Before we can use it, we need to generate a new client secret.

Also add this app with "Reader" role to the same subscription as your logic app. You can do this by going to 'Access Control' of your subscription and adding a new role assignment

Create a scheduled function app

To make use of the just created app registration we can create a scheduled function app that looks like this:

[FunctionName("Scheduled_ProcessData")]
public static async Task Run([TimerTrigger("0 */1 * * * *")]TimerInfo myTimer, ILogger log)
{
    // Do something here
}

For this example we used a function app but since access to the logic app resource is just a REST call you can access it from any solution that is able to do REST calls.

Secure it a little

Now we got the basic plumbing done What we can do now is, instead of retrieving the url from a config or from a keyvault, retrieve the url from the logic app (resource)!

In the code below we will do the following things in order:

Setup all the values need to execute the calls
Construct the url from where we can retrieve the logic app url
Retrieve the logic app url (which is not the same url you see in when editing the app)
Post a message to this new url

For this code to work you need to add the nuget for "Microsoft.Azure.Management.ResourceManager.Fluent;" and insert the using for it.

// Setup 
var tenantId = "6a76fe50-e9d9-477f-9831-e43347c8f9d4";
var clientId = "a66fcb38-c768-4afc-ab79-d544d2e147d0";
var secret = "your app password/secret here";
var subscriptionId = "554395c0-759d-4299-9134-554e608f7f68";
var resourceGroupName = "Your Azure Resource Group here";
var logicAppName = "Your Logic app name here";

// Setup resource client
var creds = new AzureCredentialsFactory().FromServicePrincipal(clientId, secret, tenantId, AzureEnvironment.AzureGlobalCloud);
var restClient = RestClient.Configure()
    .WithEnvironment(AzureEnvironment.AzureGlobalCloud)
    .WithBaseUri("https://management.azure.com/")
    .WithCredentials(creds)
    .Build();

// Construct meesage
var url = $"https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Logic/workflows/{logicAppName}/triggers/manual/listCallbackUrl?api-version=2016-06-01";
var message = new HttpRequestMessage(HttpMethod.Post, url);

// Add authentication headers on message
await restClient.Credentials.ProcessHttpRequestAsync(message, new System.Threading.CancellationToken(false));

// Retrieve logic app url
var httpClient = new HttpClient();
var httpResponse = await httpClient.SendAsync(message);
var apiResponse = await httpResponse.Content.ReadAsStringAsync();

// Send Message to logic app
var authenticatedUrl = (string)JsonConvert.DeserializeObject<dynamic>(apiResponse).value;
await httpClient.PostAsync(authenticatedUrl, new StringContent("Message to logic app"));

Let me first state that the hardcoded values in the setup is a real 'no go'. If you want to use this example please get them from a KeyVault. This can be done by adding the Managed Identity in the Access Policies of the KeyVault and using the KeyVault SDK. For simplicity I kept hardcoded values. A more detailed explanation can be found here

For now I just send an StringContent to the logic app but of course, you can send anything that the logic app is able to receive. Now run the function and wait for it to trigger a run. When the function has been executed you can see we successfully posted a message to the logic app.

The url will stay valid until the primary access key of the logic app is regenerated.

Secure it even a little further

Even though the url's to call the logic app are retrieved on runtime and not saved, the static url is still available. I must admit that the chance of that url leaking somewhere or being brute-forced is very small. To limit this even more is regenerating it every x minutes/hours/days. We can do this by basically calling the same code but with a different url and we need to add some content to the post.

Change the url to:

https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Logic/workflows/{logicAppName}/regenerateAccessKey?api-version=2016-06-01

And add this 1 row of code to add content to the message you post:

message.Content = new StringContent(JsonConvert.SerializeObject(new { keyType = "Primary" }), Encoding.UTF8, "application/json");

The 'keyType' property can be set to "Primary" or "Secondary" which will then regenerate the specified key. This is the same functionality as in the azure portal.

A nice added feature is that when changing the primary key all the retrieved logic app urls will be invalid after 10 minutes or so.

When changing the access key, keep in mind that you probably need to refresh the azure portal and wait a few minutes. It occurred a several times that, when opening the logic app runs without the portal refresh, an error was show about not being authorized to view the content like below:

Well, that is it! Now you have a solution with rolling keys for logic apps and a way to access your logic apps without configuring a URL. Of course, you have to be realistic and wonder what the change is that someone guesses/brute-force an URL and signature.. that would be kinda "remarkable". But if you are the person that wants all the extra security possible then this is maybe for you :)

Thanks for reading!