How You Can Make Mobile Apps Secure?

IT

How You Can Make Mobile Apps Secure?

Coming up with a concept for a new app is not all that difficult, but making it a reality requires a lot of strategizing, planning and outlining.

Various factors go into the app development process, and in today’s world, where hacking, cybercrime and data leaks are the norm, mobile app security needs to be taken seriously. Basically, it should be at the top of the list when starting a new app development project.

The last thing any app developer will want is for their app to go down due to a security flaw, which can only happen if security planning is not given enough importance. If you want to develop a new app, take the following tips into consideration to ensure the said app is launched successfully.

Get the Security Team Involved

Getting the security team involved from day one is a necessity rather than a luxury. When the security team is part of the development process, there is no room for error. But the team has to be incorporated in everything that has to do with the app development process; whether you are Scrumming, Rapid, Agile and SWOTing.

In case a change is made, or a revision is on the cards, get the security team on board. This way, they will guide you on how to deal with potential issues.

Testing is the Way to Go

Even though a staggering 60% of developers are not confident about their app’s security, they still do not take the appropriate steps to fix it. The problem lies in developers failing to test their apps.

QA is an important part when building security code, and it should not be an afterthought. Review every line of code, and identify potential loopholes, then fix them before the app goes live.

Don’t Assume Third Party Dependencies are Safe

It is common for developers to use codes from third parties: Why fix something that isn’t broken, right?

You need to understand and realize that third-party code is not necessarily safe, nor is it vetted. No matter what happens, don’t be one of those programmers that make do with what they have got. Be thorough about the third party modules you plan to integrate and only consider them if you are certain they are safe.

Verify APIs you intend on Using

APIs are a vital part of back-end programming, but they can be a security nightmare too, especially since they need to see the real world. For this reason, it is necessary for you to make sure that the APIs you plan on using are verified for the development platform you are using.

Think like a Hacker

When writing code, think like a hacker. Ask yourself questions like: is this exploitable? Issues that may seem minor could be a vulnerability for hackers to exploit. And if that happens, it will affect how people see your app.

While reviewing code for your app, look for ways to break it. That does not mean you stop at flaws alone. You can’t leave any stone unturned during app testing. This is especially true for mobile devices considering how they are subject to a host of environmental variables.

Minimize Permissions to Prevent Attacks

For greater security, you might as well rely on zero-trust security, since it is one of the fastest growing methods after all; that too for good reason. This method relies on the principle that nothing or no one on a network is safe, let alone secure. This translates into how the lowest possible permissions are granted to a machine or a user, and only when required.

When it comes to your mobile app too, the same principle needs to be applied. If your app does not need access to contacts or camera, then restrict the app’s access. Additionally, if it does not require an internet connection, don’t program it to require it then.

Be Wary of what is being stored on a Device

Personal data stored on any device is ripe for the taking, in which case you need to get rid of it. If that is not an option, then ensure said data is moved to a secure location instead. This includes personally identifiable and sensitive information, in which case you should encrypt it as well.

If your app deals with sensitive information, then a compromise will have to be made in one way or another. Either, it will be on your servers or on the device itself, meaning both are at risk of being compromised. While developing your app, take all the time you need to determine where user data should be stored, not only for your sake but for the users’ too regarding security.

Whether you are developing your app yourself, or through a mobile app development company, know what you are getting yourself into. Also, if you want your app to be a success, you will need to indulge into aspects like marketing strategies, so don’t expect to be done with it once your app is readily available for use.

The entire app development process is a complicated one, and if you want to get highly rated, then you will need to protect your users. As long as you play your cards right, you will be recommended to others as a reputable app choice. Read more abour mobile app development here – https://giraffestudioapps.com/top-10-mobile-app-development-challenges/.

IT

IIS URL Rewrite – one of known issues with the rewriteBeforeCache feature

I ran into IIS worker process (w3wp.exe) crash issue under specific conditions:

  1. If IIS apppool is running in the Classic mode
  2. ExtensionlessUrlHandler is configured
  3. IIS Url Rewrite outbound rule is configured with enabling with setting rewriteBeforeCache=”true”.

After investigating the issue, I found one work-around way to avoid the crash issue and hoped to share it here.  

In this case, the IIS Url Rewrite module tried to use the HttpContext object which was already deleted because the the object was created earlier while handling the extensionless URL, which is supposed to be handled with creating a child request.

The child request is created by the ExtensionlessUrlHandler module in order to complete send the response to the user and the IIS Url Rewrite module was trying to use the context after that, which is a bug of IIS URL Rewrite modle. .

Because the crash issue happens under those errorneous conditions, there are various workaround ways like this:

  1. If we use Integrated Mode instead of the Classic mode, the crash issue won’t happen because the Url Rewrite module uses a different code path.
  2. Or, if we remove the ExtensionlessUrlHandler modules, the AV issue is also fixed even though the classic mode is being used. This is because the ExtensionlessUrlHandler module does not complete sending response earlier.
  3. Finally, if we disable the rewriteBeforeCache feature, the issue can be solved as well even though we keep using the Classic mode and the ExtensionlessUrlHandler module. 

NOTE

  1. If you decided to keep rewriteBeforeCache enabled, URL Rewrite’s outbound rule won’t be applied for the extensionless requests because the ExtensionlUrlHandler sends the response ealier than Url Rewrite module.
    If you want to apply the outbound URL Rewrite rule to the extensionless requests as well, you should disable the rewriteBeforeCache feature.
  2. If rewriteBeforeCache is disabled, there can be some performance penalty. So, you should make sure optimizing the Url Rewrite outboud rules if you see any performance issue after the change.

In my opinion, disabling the rewriteBeforeCache feature is the simplest workaround way to avoid the crash issue until the bug of IIS Url Rewrite moudle is fixed.

So, here I’d like to share the way about how to disable the rewriteBeforeCache feature.

Considering the fact that the default attribute value of the rewriteBeforeCache is “false”, you can disable the feature with changing the IIS Url Rewrite ouboundRule section as the following:

    <rewrite>         <outboundRules>         …

– Or –

    <rewrite>         <outboundRules rewriteBeforeCache=”false”>
IT

IIS Container images for Windows Server 2019 are now available

Now that Windows Server 2019 is generally available, we have published IIS container images for Windows Server 2019. You can pull the new Windows Server image via-

docker pull mcr.microsoft.com/windows/servercore/iis:windowservercore-ltsc2019

As you may have noticed in the docker pull command, the image is now being served from the Microsoft Container Registry (MCR). Starting with Windows Server 2019 and going forwards, all new tags will be published exclusively to MCR. All existing tags have been syndicated from DockerHub to MCR.

If your existing Dockerfile begins by specifying microsoft/iis as the base layer as shown below-

FROM microsoft/iis:windowsservercore-ltsc2016…

Our guidance is to move to adopting MCR as your base layer. You should change your Dockerfile to what’s shown below-

FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2016…

As part of this transition, we are only changing the source from where you download your images to MCR. DockerHub continues to be the preferred medium for container image discovery. I encourage taking a look a Steve Lasker’s blog post taking about the value proposition we can offer our customers through MCR.

IIS Images on Nanoserver are no longer supported

In the past, we’ve published IIS container images based upon the Nanoserver base image for sac2016 (microsoft/nanoserver). As outlined in the Windows Server Semi-Annual Channel Overview, microsoft/nanoserver:sac2016 has passed 18 months from it’s original release date and is no longer supported. As a consequence, we have decided to stop publishing the IIS on Nanoserver image.

Existing images continue to be available, but we strongly caution against using them as they are no longer supported. Our guidance would be to recommend you move to the IIS images based on Windows Server Core.

Also, if you need help with Microsoft .Net development, you can always contact the dot net development company – Dataxdev

We look forward to your feedback regarding these new changes. Let us know in the comments or send me a tweet.

IT

How to use the IIS Insider docker tag

I’d like to explain the basic usage of the microsoft-windows-servercore-iis-insider docker tag so that you can use it easily.

In addition, I want to introduce a new feature, which is currently available with the insider version of IIS docker tag.

The new feature is to make the docker log from IIS ETW logging so that you can get the IIS activity that is happenning inside of the docker container immediately.

Once you understand about how to use the new feature, you will also want to try the new feature with the other existing IIS tags and that is possible with making your own Dockerfile.

I have explained about how to apply the new feature with the existing iis tags as well here.

The new feature is powered by using the logmonitor.exe with a predefined LogMonitorConfig.json in order to expose the IIS Etw logging to the logmonitor.exe.

If you want to include other data, you can customze LogMonitorConfig.json, referring to the LogMonitor instruction.

Using the IIS Insider docker tag

1. Prepare a docker host machine referring to the microsoft-windows-servercore-insider instruction

NOTE: The current latest IIS insider tag is compatible to windowsservercore-10.0.19035.1

2. Run a IIS docker with running

docker run –name TestIisInsider –interactive –tty –rm –publish 5000:80 mcr.microsoft.com/windows/servercore/iis/insider:windowsservercore-10.0.19035.1   – Or –   docker run -n TestIisInsider -i -t –rm -p 5000:80 mcr.microsoft.com/windows/servercore/iis/insider:windowsservercore-10.0.19035.1
NOTE: mcr.microsoft.com/windows/servercore/iis/insider:windowsservercore-10.0.19035.1

This is the IIS Insider tag name. With the tag name, you can notice that it is made from a certain version (10.0..19351.1) of the windowsservcore insider tags

–name TestIisInsider

This allows to set the docker id with “TestIisInsider” for the new docker container. This is optional if you don’t use the docker id later.  –interactive and –tty

These options allow to send the docker control signals such as Ctrl-C. If you don’t need to use the control signal, you don’t need to specify these docker options –rm

This is to remove the docker container automatically when it is stopped. If you don’t want to remove the docker container, you don’t need to specify the docker option –publish 5000:80

This is to publish the tcp port 5000 of the host machine and map to the tcp port 50 of the docker container. If you want to use other port, you can adjust the port values

3. Open a web browser and send a request http://localhost:5000

4. If everything works, you will get the response from the Default Web Site of the newly created docker container and the console of the docker client will show the IIS ETW event log as the following example:

C:\> docker run –interactive –tty –rm -p 5000:80 mcr.microsoft.com/windows/servercore/iis/insider:windowsservercore-10.0.19035.1 …   <Source>EtwEvent</Source><Time>2020-02-03T19:44:22.000Z</Time><Provider idGuid=”{7E8AD27F-B271-4EA2-A783-A47BDE29143B}”/ ><DecodingSource>DecodingSourceXMLFile</DecodingSource><Execution ProcessID=”8092″ ThreadID=”8792″ /><Level>Information< /Level><Keyword>0x8000000000000000</Keyword><EventID Qualifiers=”6200″>6200</EventID><EventData><EnabledFieldsFlags>2478 079</EnabledFieldsFlags><date>2020-02-03</date><time>19:44:19</time><c-ip>10.121.100.145</c-ip><cs-username>-</cs-userna me><s-sitename>W3SVC1</s-sitename><s-computername>1b1ccba0391d</s-computername><s-ip>172.18.164.253</s-ip><cs-method>GET … <sc-substatus>0</sc-substatus><CustomFields></CustomFields></EventData>


 5. In order to stop the IIS docker, you can type Ctrl-C from the console of the docker client and you will see the docker container getting stopped automatically with the below log information.

… CTRL signal received. The process will now terminate. [2020-02-03T19:53:56.000Z][LOGMONITOR] INFO: Entrypoint processs exit code: -1073741510

NOTE:

  • You can also stop the IIS insider docker container with stopping the w3svc service with running “net stop w3svc” command as the following:
C:\> docker exec TestIisInsider net stop w3svc The World Wide Web Publishing Service service is stopping. The World Wide Web Publishing Service service was stopped successfully.

How to apply the new feature to existing IIS tags

In order to use the new feature with other existing IIS tags, you can write your own docker file with referring to the dockerfile of the IIS Insider docker tag

Here is one example of the Dockerfile which enables the new feature to the existing mcr.microsoft.com/windows/servercore/iis docker tag.