Secure Code Warrior C# Basic OWASP Web Top 10 2017 5: Broken Access Control, 6: Security Misconfiguration and 7: XSS vulnerabilities

Learn the ropes or hone your skills in secure programming here. These challenges will give you an understanding of 5: Broken Access Control, 6: Security Misconfiguration and 7: XSS vulnerabilities

5: Broken Access Control,

Access Control - Missing Function Level Access Control

An incorrect implementation when checking the roles in the user claims will allow a malicious actor to have access without the corresponding authorized role.

Role checking has to be based on an allowed list. The role-based authorization checks if any of the user's roles contains in the allowed roles list. In this case, allowed users will get their access, and the rest won't.

Access Control - Insecure Direct Object Reference

Using a request parameter to allow access to research documents may allow a malicious actor to download unauthorized documents from other users.

不能通过request参数去获取用户id，因为外部传递的数据可能被篡改

 if (_userClaims.UserId != research.OwnerId) 这种才是正确的

Internal application objects should not be directly accessible using request parameters that could be manipulated by an attacker. The application is using the UserId from the user claim instead of the request parameter to find the research document and check the ownership. In this way, an adversary manipulating the request parameter would not be able to have access to sensitive documents.

Access Control - Insecure Direct Object Reference

When referencing a research file to download it, an incorrect ownership check will allow a malicious user to have access to someone else’s research documents.

It is recommended to implement appropriate checks when referencing a research document for downloading. The application is ensuring user ownership before allowing the download. In this way, a malicious actor will not have access to other users' research files.

6: Security Misconfiguration

Security Misconfiguration - Debug Features Enabled

       if (!Debugger.IsAttached && debugEnabled)

                {

                    Logger.LogDebug(e.Message + e.StackTrace);

                }

The application tried to log stack trace data only when the debug mode is enabled and there is a debugger attached. However, an incorrect configuration will cause full stack traces to be logged when running in production (where typically there is no debugger attached).

正确写法

bool.TryParse(ConfigurationManager.AppSettings["Debug"] ?? "false", out var debugEnabled);

  if (Debugger.IsAttached && debugEnabled)

                {

                    Logger.LogDebug(e.Message + e.StackTrace);

                }

It is not recommended to have debug features enabled in production environments. A configuration flag was added with a default value of false. The application ensures that if there is a debugger attached and if the debug mode is enabled, only then, the full stack trace will be logged.

Security Misconfiguration - Information Exposure

Returning the full stack trace when an error happens may allow a malicious actor to take advantage of the returned information, which may include internal details of the application, to carry out further attacks.

 try

            {

                return _next.Handle(input);

            }

            catch (ServerException e)

            {

                return new CommonResponse(e.Message);

            }

            catch (Exception e)

            {

                Console.WriteLine(e.Message);

                return new CommonResponse("Internal server error.");

            }

It is recommended to avoid returning detailed internal information when an exception occurs. The application is returning a generic message without attaching the full stack trace of the error. In this way, no valuable information will be provided to malicious actors.

Information Exposure - Error Details

      catch (Exception e)

            {

                _appLogger.LogError(e);

                return new FailedResponse<TOut>(e.Message);

            }

Displaying full error message details when an exception occurs, may disclose internal application details to malicious actors that would use such information to carry out further attacks.

        catch (DomainException domainException)

            {

                return new FailedResponse<TOut>(domainException.Message);

            }

            catch (Exception e)

            {

                _appLogger.LogError(e);

                return new FailedResponse<TOut>("Some error occurred");

            }

        }

It is recommended to avoid returning too much information when an exception occurs. The application is using a custom exception to catch related domain errors and it is returning a generic message for other exceptions. In this way, only the needed information is returned to the user and a malicious actor will not be provided with internal application information.

7: XSS vulnerabilities

Cross-Site Scripting (XSS) - Stored Cross-Site Scripting

   @Html.Raw(Model.Information)

改进

 

<httpRuntime targetFramework="4.7" encoderType="System.Web.Security.AntiXss.AntiXssEncoder" />

Unescaped user input is displayed in the browser. An adversary could insert HTML and alter the appearance of the page, or could execute malicious scripts.

              string information = reader["Information"].ToString();

                        userModel.Information

                            = ValidateAntiXSSUserInput(information);

ASP.NET MVC has a built-in protection against Cross-Site Scripting (XSS). However, sometimes HTML must be allowed. This is done via the [AllowHTML] as an attribute of the property in the model class. To safeguard the application from Stored XSS, the System.Web.Security.AntiXss library can be used, which contains methods to encode HTML input that needs to be displayed in the browser.

 

Cross-Site Scripting (XSS) - Stored Cross-Site Scripting

Unescaped user input is displayed in the browser. An adversary could insert HTML and alter the appearance of the page, or could execute malicious scripts. 

          @Html.Raw(item.Description)

换成

       @Html.DisplayFor(modelItem => item.Description)

The DisplayFor() in the Razor page will provide an output of encoded HTML and will prevent scripts from running. However, malicious scripts can still be embedded in the site.

ASP.NET MVC has a built-in protection against Cross-Site Scripting (XSS). However, sometimes HTML must be allowed. This is done via the [AllowHTML] as an attribute of the property in the model class. To safeguard the application from Stored XSS, the System.Web.Security.AntiXss library can be used, which contains methods to encode HTML input that needs to be displayed in the browser.

 

Cross-Site Scripting (XSS) - Reflected Cross-Site Scripting

The [ValidateInput(false)] attribute on the controller level explicitly allows HTML elements as input. 

name = AntiXssEncoder.HtmlEncode(name, false);

The AntiXss library contains methods to protect the application against XSS attacks. The user input is encoded and displayed in the browser.