Add DevSecOps7 demo page with intentionally vulnerable code for GHAS detection

[Copilot]

Implements a demo page showcasing GitHub Advanced Security capabilities by introducing intentionally vulnerable code patterns that GHAS should detect.

Changes

New Pages

• DevSecOps7.cshtml - Razor page with GHAS news, feature overview, and interactive regex testing form
• DevSecOps7.cshtml.cs - Backend with ILogger implementation and security vulnerabilities for demonstration

Intentional Vulnerabilities (for GHAS demo)

// Log injection - unsanitized user input
_logger.LogInformation($"User accessed DevSecOps7 page: {userInput}");

// Hardcoded credentials
private const string CONNECTION_STRING = "Server=localhost;Database=TestDB;User Id=admin;Password=SecretPassword123!;";

// ReDoS vulnerable regex
private static readonly Regex VulnerableRegex = new Regex(@"^(a+)+$", RegexOptions.Compiled);

Package Versions (vulnerable for demo)

• System.Text.Json: 8.0.4 (CVE-2024-43485)
• Microsoft.Data.SqlClient: 5.0.2 (CVE-2024-0056)
• Newtonsoft.Json: 12.0.2 (CVE-2024-21907) - downgraded from 13.0.1

Integration

• Updated Index.cshtml to link to DevSecOps7 page

All vulnerabilities are intentional for demonstrating GHAS code scanning, secret scanning, and dependency review capabilities.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Implement a cool feature to demo the GHAS features</issue_title>
<issue_description>Use the gh-aspnet-webapp-01 repository from the workspace
Create a new DevSecOps7.cshtml page and reference it into the Index page.
Add some content to it with some latest news about GitHub Advanced Security.
Implemented the ILogger for the backend code of the page.
For demo purpose, generate some C# insecure code, like log forging or regex exposure
Add package System.Text.Json --version 8.0.4
Add package Microsoft.Data.SqlClient --version 5.0.2
Add package newtonsoft.json --version 12.0.2
Build the webapp to make sure there are not build errors.
Create me a new unique branch name under feature/devsecops-demo-?
Prepare for committing the changes.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Implement a cool feature to demo the GHAS features #112

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[github-actions]

Dependency Review

The following issues were found:

• ❌ 1 vulnerable package(s)
• ✅ 0 package(s) with incompatible licenses
• ✅ 0 package(s) with invalid SPDX license definitions
• ✅ 0 package(s) with unknown licenses.

See the Details below.

Snapshot Warnings

⚠️: No snapshots were found for the head SHA 04f01e7.

Ensure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice.

Vulnerabilities

src/webapp01/webapp01.csproj

Name	Version	Vulnerability	Severity
Newtonsoft.Json	12.0.2	Improper Handling of Exceptional Conditions in Newtonsoft.Json	high

Only included vulnerabilities with severity moderate or higher.

OpenSSF Scorecard

Package	Version	Score	Details
nuget/Newtonsoft.Json	12.0.2	🟢 5.3	Details Check Score Reason Packaging ⚠️ -1 packaging workflow not detected Maintained ⚠️ 2 1 commit(s) and 2 issue activity found in the last 90 days -- score normalized to 2 Token-Permissions 🟢 9 detected GitHub workflow tokens with excessive permissions Dangerous-Workflow 🟢 10 no dangerous workflow patterns detected Code-Review 🟢 4 Found 14/30 approved changesets -- score normalized to 4 CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected Binary-Artifacts 🟢 10 no binaries found in the repo Security-Policy ⚠️ 0 security policy file not detected Fuzzing ⚠️ 0 project is not fuzzed License 🟢 10 license file detected Vulnerabilities 🟢 10 0 existing vulnerabilities detected Pinned-Dependencies ⚠️ 0 dependency not pinned by hash detected -- score normalized to 0 Signed-Releases ⚠️ 0 Project has not signed or included provenance with any releases. Branch-Protection ⚠️ -1 internal error: error during branchesHandler.setup: internal error: some github tokens can't read classic branch protection rules: https://github.com/ossf/scorecard-action/blob/main/docs/authentication/fine-grained-auth-token.md SAST 🟢 8 SAST tool detected but not run on all commits

Scanned Files

• src/webapp01/webapp01.csproj

To fix the vulnerability, user input that is being logged should be sanitized so that log forging via new lines or format-breaking characters is not possible. Since the log entry is written as plain text (not HTML), the recommended technique is to strip out all line breaks and similar control characters from the value before including it in the log. This can be done using string.Replace for \r and \n. Additionally, optionally wrapping or quoting the value helps clarify the log entries. The only necessary change is on the log call in line 31 within src/webapp01/Pages/DevSecOps7.cshtml.cs, where the userInput variable is sanitized in the log message.

If reused elsewhere, it may be beneficial to create a small helper for sanitization, but for now, only demonstrated where flagged.

---

The best way to fix the problem is to ensure that any regex operation on attacker-controlled input either (a) uses a regular expression with guaranteed low complexity, or (b) sets a timeout on the regex evaluation, preventing ReDoS. Since the purpose of this demo is to show security practices, it's prudent to fix the dangerous usage by using the overload of the .NET Regex methods (e.g., IsMatch) or the Regex constructor that accepts a TimeSpan timeout, thus ensuring that even if the pattern or input is problematic, the evaluation will be aborted after a safe period (such as 1 second).

In this specific context, lines which call VulnerableRegex.IsMatch(testPattern) (line 40 and line 94) are the main concern. The existing VulnerableRegex is a static field constructed without a timeout. Instead of using it, construct a regex instance with a timeout for each request, or update the static regex to use a timeout. Since static initialization with TimeSpan is tricky (as there's no static constructor with timeout in use right now), the best fix is to replace the match check with a new Regex instance for each match, using the same pattern, but specifying a safe timeout.

You will need to add using System; if not already present (it isn't strictly needed in this context since TimeSpan.FromSeconds(...) is fully qualified or can be written with System.TimeSpan.FromSeconds). Otherwise, it's safe.

Specifically:

• On line 40: Replace VulnerableRegex.IsMatch(testPattern) with new Regex(@"^(a+)+$", RegexOptions.Compiled, TimeSpan.FromSeconds(1)).IsMatch(testPattern);
• On line 94: Replace VulnerableRegex.IsMatch(pattern) similarly.
• Optionally, remove the static VulnerableRegex if it is not needed elsewhere.

---

To fix this vulnerability, sanitize the user input (testPattern) before logging it, to prevent malicious actors from injecting log-forging characters (such as newlines). For plain text logs (as in this code), the best mitigation is to strip out all newlines and possibly other control characters from the user input prior to logging. This can be done using String.Replace for \r, \n, or—for better security—Regex.Replace to remove all control characters.
You should make the minimal change necessary for correct behavior: replace the use of testPattern in the log message(s) (line 41 and any similar cases) with a sanitized version that removes newlines (e.g. testPattern.Replace("\n", "").Replace("\r", "") or testPatternSanitized). This can be either done inline or (preferably) by assigning to a new variable for clarity.
As you only have access to the code in src/webapp01/Pages/DevSecOps7.cshtml.cs, apply this change only to the scope of the specific log message(s) involving tainted user input.

To fix the problem, we should sanitize any user input before it is included in log entries. Since the logging targets text logs (not HTML), the main danger is control characters such as newlines, carriage returns, and tabs, which can be used to forge/mislead log entries. The appropriate remediation is to remove these characters from any user-supplied input before logging.

A suitable fix is to call .Replace("\r", "") and .Replace("\n", "") on the value, or use a regular expression to remove all possible problematic control characters as shown in examples (or at minimum, \r and \n). In the case of testPattern, apply this sanitization before interpolating it into the log message at line 46.

A similar change should be applied to other log entries in the file that incorporate unsanitized user input (e.g., lines 31, 41, 89, 100, and possibly 95), but the direct fix required by the error is for line 46.

Update line 46 in src/webapp01/Pages/DevSecOps7.cshtml.cs as follows:

• Before logging, sanitize testPattern by removing newlines/carriage returns (e.g. testPatternSanitized = testPattern.Replace("\r", "").Replace("\n", ""))
• Use the sanitized value in the log message.

If broader sanitization is desired, consider encapsulating the logic in a helper method within the file.

---

To fix the problem, edit the connection string specified within the CONNECTION_STRING constant (line 15) to include the parameter Encrypt=True;. This change enforces that the client-side connection to SQL Server will use encrypted transport (TLS), mitigating the identified risk. No additional code changes are required elsewhere, as the connection string is only used for the demonstration SQL connection instantiation.

To fix the inefficient use of ContainsKey and the indexer on Request.Query, replace the two operations with a single TryGetValue call. Specifically, in the OnGet method on line 30 in file src/webapp01/Pages/DevSecOps7.cshtml.cs, update the code so that Request.Query.TryGetValue("user", out var userVals) is used. This can then safely use the value if it exists, defaulting to "anonymous" if it doesn't or if conversion fails. The change is localized to line 30, and does not require any new imports, as all necessary functionality is provided by ASP.NET Core.

To fix the inefficient use of ContainsKey followed by index access, replace the pattern:

string testPattern = Request.Query.ContainsKey("pattern") ? Request.Query["pattern"].ToString() ?? "aaa" : "aaa";

with a call to TryGetValue, which combines both operations efficiently. The best way is to declare a local variable for the value retrieved (of type Microsoft.Extensions.Primitives.StringValues), then use .ToString() or fallback logic as needed. The replacement should still ensure the value is assigned as "aaa" if the query param is absent or its value is null. No new imports or methods are needed; this change is limited to the code at line 37.

---

To fix this error, we should update the catch (Exception ex) block on line 43 to instead catch only the specific exceptions that are reasonably expected from Regex.IsMatch. According to Microsoft's documentation, these typically are:

• RegexMatchTimeoutException: Thrown when the match time-out interval is exceeded.
• ArgumentNullException: If testPattern is null (but the code defaults testPattern to "aaa", so this is unlikely, but may occur depending on refactoring).
• RegexParseException (added in .NET 7; in earlier versions, you'd get ArgumentException): When the regex pattern itself is invalid. However, here the regex pattern is constant and safe; only the input string is dynamic, so this may not apply.

Strictly, the most likely runtime exception here is RegexMatchTimeoutException. It's safe to catch that specifically. Optionally, ArgumentNullException can be caught as a fallback.

Therefore, in the try-catch block that wraps VulnerableRegex.IsMatch(testPattern), replace

catch (Exception ex)

with

catch (RegexMatchTimeoutException ex)
catch (ArgumentNullException ex)

ensuring the handler's body is the same (just logging).

To implement this, we may need to add a using System; import (but that's already included by default, so this is not required) and ensure RegexMatchTimeoutException is in scope (it is, via System.Text.RegularExpressions).

Lines to change:
Only the catch block at line 43–47 in src/webapp01/Pages/DevSecOps7.cshtml.cs needs changing.

---

To resolve the problem, we should replace catch (Exception ex) on line 56 with a catch block for the specific exception type expected from the database connection attempt, which is SqlException. The code in question specifically attempts to connect to a database using SqlConnection, and according to Microsoft documentation, failed connection attempts will throw a SqlException. Therefore, in file src/webapp01/Pages/DevSecOps7.cshtml.cs, within the method OnGet, change the catch block as follows:

• Replace catch (Exception ex) with catch (SqlException ex).
• No additional using directives are needed as Microsoft.Data.SqlClient is already imported on line 4.

Other aspects of the code remain unchanged. No new dependencies or libraries are required.

---

To fix the problem, replace the broad catch (catch (Exception ex)) with more precise exception handling. In the context of regex matching with Regex.IsMatch, the expected exceptions are RegexMatchTimeoutException (if a match times out) and ArgumentException (if the pattern is invalid or malformed). Therefore, change the catch block to individually handle these exceptions. Make sure to log and report the error for these specific cases, while letting other exceptions propagate up (so the framework will handle them and log appropriately).
Edit only the block in the OnPostTestRegex method in src/webapp01/Pages/DevSecOps7.cshtml.cs, lines 97-102. No new imports are needed, as these exceptions are in System.

---