Approaches To Security Misconfiguration

Security misconfiguration typically occurs when holes are left in the security framework of an application. These security misconfigurations can lead an attacker to enter into the system and results in an unauthorized access to perform many actions. Attackers find these misconfigurations through an unauthorized access to default accounts, unprotected files, unused webpages, directories and unpatched flaws and more. If a system is not properly handled for the security configurations, then the data can be stolen or modified slowly over time, which is a bit costly to recover.

There are many security flaws for your Application leakage and a few are listed below:

  1. Missing Custom Error Handling

    This can happen if you are not handling the runtime errors properly and showing the actual errors to the front end which are generated during execution time like the below screenshots.


    With the above screenshot, the hacker can easily understand your security flaws in your Application, which results in the hacker will get an opportunity with more information to inject some malicious code into your Application.

    You can prevent this type of issue in many ways,

    • If you are using any routing mechanism, then you can redirect to your error page.
    • If you are using any custom exception message class, then you can customize the error message and send it back to the front end.
    • If you are using any custom errors tag in web.config file like <customErrors/>, then you can configure error handling mechanisms in your web.config file.

  2. Configure sensitive information in configuration file

    If you are configuring any sensitive information in your Application’s Web/app config, the file will be shown, as below:

    config file
    config file

    This means that you are allowing hackers to steal your sensitive information. If you are using Handler in your Application project, then the Hacker can use the URL requested, below:


    Ex http://localhost:62887/QueryStringHandler.ashx?file=/web.config


    You can prevent this type of issue in many ways, which are:

    • Remove all the sensitive information from your Application config file and keep only framework related information.
    • You can place your sensitive information in other Servers and from where they are, you can read the sensitive information at the Server side.
    • You can place your sensitive information in your physical drive where you can read it when you need to.
    • You can encrypt your config file to prevent theft.

  3. JavaScript code

    As the JavaScript code is not safe at the client side, the hacker can modify the script code by injecting his malicious code, which means we are allowing the hacker to inject some malicious code.

    You can prevent hackers from injecting malicious code into JavaScript files.

    Nowadays, we have many tools available online to obfuscate the JavaScript code and for testing purposes, you can use one of them.

    Obfuscate the JavaScript code, which has been created in the solution.

    JavaScript Code


    1. var TPF = {  
    2.             appendHead: function (o) {  
    3.                 var count = 0;  
    4.                 var scriptTag, linkTag;  
    5.                 var scriptFiles = o.js;  
    6.                 var jsFilesLen = scriptFiles.length;  
    7.                 var cssFiles = o.css;  
    8.                 var head = document.getElementsByTagName('head')[0];  
    9.                 var self = this;  
    10.                 for (var k = 0; k < jsFilesLen; k++) {  
    11.                     scriptTag = document.createElement('script');  
    12.                     scriptTag.type = 'text/javascript';  
    13.                     if (typeof o.callback == "function") {  
    14.                         if (scriptTag.readyState) {  //IE  
    15.                             scriptTag.onreadystatechange = function () {  
    16.                                 if (this.readyState == "loaded" || this.readyState == "complete") {  
    17.                                     count++;  
    18.                                     this.onload = self.initMethod(count, jsFilesLen, o.callback);  
    19.                                 }  
    20.                             };  
    21.                         } else { // other browsers  
    22.                             scriptTag.onload = function () {  
    23.                                 count++;  
    24.                                 if (count == jsFilesLen);  
    25.                             };  
    26.                         }  
    27.                     }  
    28.                     scriptTag.src = scriptFiles[k];  
    29.                     head.appendChild(scriptTag);  
    30.                 }  
    31.                 for (var k in cssFiles) {  
    32.                     linkTag = document.createElement('link');  
    33.                     linkTag.type = 'text/css';  
    34.                     linkTag.rel = 'stylesheet';  
    35.                     linkTag.href = cssFiles[k];// + "?urlUID=" + uniqueID;  
    36.                     head.appendChild(linkTag);  
    37.                 }  
    38.             },  
    39.             initMethod: function (curLen, total, callMethod) {  
    40.                 if (curLen == total);  
    41.             }  
    42.         };  
    44.         function loadClientSideFiles() {  
    45.             TPF.appendHead({  
    46.                 css: ['/Content/css/bootstrap.min.css',  
    47.                       '/Content/css/ie10-viewport-bug-workaround.css',  
    48.                       '/Content/css/dashboard.css'],  
    49.                 js: [                       
    50.                      '/APP/Requestor/requestorController.js',  
    51.                      '/APP/Approver/approverController.js'],  
    52.                 callback: function () {  
    53.                     // all needed JS,CSS files are loaded completely, render the editor now:  
    54.                     //loadComponents();  
    55.                 }  
    56.             });  
    57.         }  
    58.         $(function () {  
    59.             loadClientSideFiles();  
    60.         });  
    Obfuscate your code

    JavaScript Obfuscator renders the JavaScript source code into obfuscated format with completely unreadable form, which results in preventing it from being analyzed and stolen from unauthorized access.

    For testing purposes, you can obfuscate your JavaScript code from this site.



  4. Debugging Enabled in production environment

    Debugging enabled in production environment is not a good practice because debugging messages help attackers to plan a form of attack into your Application.

    The debug attribute of the <compilation> tag in the config file defines whether the compiled binaries should include debug information. ".pdb" file tells the debugger how to find the original source files for a binary and tells how to map the breakpoints in the code to lines in those source files.

    Debugging enabled in a production environment is dangerous, because you are providing inside information to the end user, who should not have access to your Application and it may cause an attack on your Application.

    Typical misconfiguration

    Typical misconfiguration

    Secure use


  5. Tracing attribute Enabled

    This feature of .NET is very useful for the developers and programmers in a development environment to debug and profile your Applications. In a production environment, this feature should be disabled; if unfortunately the tracing attribute is enabled in the production environment, then it is dangerous because it is also one of the most useful tools that the hacker can use to attack your Application if this attribute is enabled in your Application.

    Typical misconfiguration


    When tracing is enabled in your Application, then the hacker can simply browse trace.axd file to view the detailed list of the recent requests made to the Application

    Secure use


  6. String Authentication and Authorization

    In the Application, if we are not properly authenticated or authorized throughout the Application, then we are allowing the hacker to get into the system.

    Use strong authentication and authorization mechanisms to validate users before granting access into the Application.

Similar Articles