Tuesday 4 July 2017
Wednesday 1 February 2017
Review on Cross-site Scripting
A3 Cross-Site Scripting
Cross-site scripting flaws can be difficult to identify and remove from a web application. The best practice to search for flaws is to perform an intense code review and search for all places where user input through a HTTP request could possibly make its way into the HTML output.
Code reviewer needs to closely review.
1. That untrusted data is not transmitted in the same HTTP responses as HTML or JavaScript.
2. When data is transmitted from the server to the client, untrusted data must be properly encoded in JSON format and the HTTP response MUST have a Content-Type of application/json. Do not assume data from the server is safe. Best practice is to always check data.
3. When introduced into the DOM, untrusted data MUST be introduced using one of the following APIs: a. Node.textContent b. document.createTextNode c. Element.setAttribute (second parameter only) Code reviewer should also be aware of the HTML tags (such as <img src..> <iframe...> <bgsound src ...>) that can be used to transmit malicious JavaScript.
In Asp.net Use Microsft’s Anti-XSS library
.NET ASPX
1. On ASPX .Net pages code review should check to make sure web config file does not turn off page validation.
2. .Net framework 4.0 does not allow page validation to be turned off. Hence if the programmer wants to turn off page validation the developer will need to regress back to 2.0 validation mode.
3. Code reviewer needs to make sure page validation is never turned off on anywhere and if it is understand why and the risks it opens the organization to.
PHP
There are two scenarios when it comes to XSS, each one to be mitigated accordingly
If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). However, this is not recommended. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.
Instead of this, you should use a template engine that applies HTML escaping by default
• Don't have a trusted section in any web application. Many developers tend to leave admin areas out of XSS mitigation, but most intruders are interested in admin cookies and XSS. Remove every instance of echo, print, and printf from your application and replace them with a secure template engine.
• HTTP-Only cookies are a very good practice, for a near future when every browser is compatible. Start using them now. (See PHP.ini configuration for best practice)
• The function declared above, only works for valid HTML syntax. If you put your Element Attributes without quotation, you're doomed. Go for valid HTML.
• Not every PHP installation has a working mhash extension, so if you need to do hashing, check it before using it. Otherwise you can't do SHA-256
• Not every PHP installation has a working mcrypt extension, and without it you can't do AES. Do check if you need it.
Note: These are Highlighted Points from Owasp Secure code Review Guide.
Cross-site scripting flaws can be difficult to identify and remove from a web application. The best practice to search for flaws is to perform an intense code review and search for all places where user input through a HTTP request could possibly make its way into the HTML output.
Code reviewer needs to closely review.
1. That untrusted data is not transmitted in the same HTTP responses as HTML or JavaScript.
2. When data is transmitted from the server to the client, untrusted data must be properly encoded in JSON format and the HTTP response MUST have a Content-Type of application/json. Do not assume data from the server is safe. Best practice is to always check data.
3. When introduced into the DOM, untrusted data MUST be introduced using one of the following APIs: a. Node.textContent b. document.createTextNode c. Element.setAttribute (second parameter only) Code reviewer should also be aware of the HTML tags (such as <img src..> <iframe...> <bgsound src ...>) that can be used to transmit malicious JavaScript.
In Asp.net Use Microsft’s Anti-XSS library
.NET ASPX
1. On ASPX .Net pages code review should check to make sure web config file does not turn off page validation.
2. .Net framework 4.0 does not allow page validation to be turned off. Hence if the programmer wants to turn off page validation the developer will need to regress back to 2.0 validation mode.
3. Code reviewer needs to make sure page validation is never turned off on anywhere and if it is understand why and the risks it opens the organization to.
PHP
There are two scenarios when it comes to XSS, each one to be mitigated accordingly
If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). However, this is not recommended. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.
Instead of this, you should use a template engine that applies HTML escaping by default
• Don't have a trusted section in any web application. Many developers tend to leave admin areas out of XSS mitigation, but most intruders are interested in admin cookies and XSS. Remove every instance of echo, print, and printf from your application and replace them with a secure template engine.
• HTTP-Only cookies are a very good practice, for a near future when every browser is compatible. Start using them now. (See PHP.ini configuration for best practice)
• The function declared above, only works for valid HTML syntax. If you put your Element Attributes without quotation, you're doomed. Go for valid HTML.
• Not every PHP installation has a working mhash extension, so if you need to do hashing, check it before using it. Otherwise you can't do SHA-256
• Not every PHP installation has a working mcrypt extension, and without it you can't do AES. Do check if you need it.
Note: These are Highlighted Points from Owasp Secure code Review Guide.
Code Review on SQL Injection
A1 Injection(SQL Injection)
The main reason for the cause of SQL Injection vulnerabilities..
1. SQL commands are not protected from the untrusted input. SQL parser is not able to distinguish between
The issue is this coding technique does not tell the parser which part of the statement is code and which part is data. This allows the attacker to modify the SQL statement by adding code to the data that was visible from the web site for the attacker to manipulate.
The main reason for the cause of SQL Injection vulnerabilities..
1. SQL commands are not protected from the untrusted input. SQL parser is not able to distinguish between
The issue is this coding technique does not tell the parser which part of the statement is code and which part is data. This allows the attacker to modify the SQL statement by adding code to the data that was visible from the web site for the attacker to manipulate.
What to Review
1. Always validate user input by testing type, length, format, and range.
2. Test the size and data type of input and enforce appropriate limits.
3. Test the content of string variables and accept only expected values. Reject entries that contain binary data, escape
sequences, and comment characters.
4. When you are working with XML documents, validate all data against its schema as it is entered.
5. Never build SQL statements directly from user input.
5. Never build SQL statements directly from user input.
6. Use stored procedures to validate user input, when not using stored procedures use SQL API provided by platform.
i.e. Parameterized Statements.
7. Implement multiple layers of validation.
8. Never concatenate user input that is not validated. String concatenation is the primary point of entry for script
injection.
9. You should review all code that calls EXECUTE, EXEC, any SQL calls that can call outside resources or command line.
Source :- OWASP Code Review Guide V2.0
Source :- OWASP Code Review Guide V2.0
The Security Warrior: WebApplication Security Checklist
The Security Warrior: WebApplication Security Checklist: Please find WebApplication Security Checklist inline with Open Web Application Security Project http://www.yourfilelink.com/get.php?fid=13...
Sunday 15 January 2017
Steps to verify Certificate Pining is implemented or not
Static method
Once the APK has been disassembled we will need to locate where within the smali source code the certificate pinning checks are done. Searching the smali code for keywords such as “X509TrustManager”, “cert”, “pinning”, etc, should point you in the right direction.
In this case a search for “X509TrustManager” returned a result within the Ex:‘smali/com/TrustEveryoneTrustManager.smali’ file. This file contains methods named “checkClientTrusted”, “checkServerTrusted” and “getAcceptedIssuers”.
If you do not find X509TrustManager certificate in smali files Certificate Pinning is not implemented.
Please follow the link below to implement Certificate Pinning
https://moxie.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/
Subscribe to:
Posts (Atom)