Here are just a few highlights of the WebInspect 9.10 release:
WebInspect-Realtime is a breakthrough integration with Fortify SecurityScope which allows for improved accuracy and confirmation of vulnerabilities.
Flexible Vulnerability Grid supports fine grained grouping and filtering of results.
Exclusion Management makes it easier to exclude parts of the web application from a scan.
Manual Locations enables the user to add files and pages to the scan results that were not found during the automatic scan. This helps to integrate vulnerability information from external sources and create a comprehensive view of vulnerabilities in the application.
Web Services received additional improvements including WS-Security support and new attacks.
More details @ http://h30499.www3.hp.com/t5/WebInspect/WebInspect-9-10-Released/td-p/4803441
Thanks & stay secure,
Somen
Saturday, July 2, 2011
Thursday, June 9, 2011
Thick Client Security Testing
1)Thick client and server using HTTP to communicate
2)Thick client and server using HTTP over SSL to communicate
3)Thick client and server using a proprietary
4)TCP protocol to communicate (without any encryption)
5)Thick client and server using a proprietary
6)TCP protocol over SSL to communicate
7)Thick client and server using a proprietary
8)TCP protocol and shared key / custom cryptography to communicate
Tools To Test Thick Client Server Communications
Fiddler HTTP Proxy - http://www.fiddler2.com/fiddler2/
EchoMirage - http://www.bindshell.net/tools/echomirage
Microsoft Detours - http://research.microsoft.com/enus/projects/detours/
Keytool command - http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html
Openssl command - http://www.openssl.org/docs/apps/req.html#EXAMPLES
Reference:
https://www.owasp.org/images/e/e7/Thick_Client_(In)Security_-_Neelay_S_Shah_-_Mar_24.pdf
2)Thick client and server using HTTP over SSL to communicate
3)Thick client and server using a proprietary
4)TCP protocol to communicate (without any encryption)
5)Thick client and server using a proprietary
6)TCP protocol over SSL to communicate
7)Thick client and server using a proprietary
8)TCP protocol and shared key / custom cryptography to communicate
Tools To Test Thick Client Server Communications
Fiddler HTTP Proxy - http://www.fiddler2.com/fiddler2/
EchoMirage - http://www.bindshell.net/tools/echomirage
Microsoft Detours - http://research.microsoft.com/enus/projects/detours/
Keytool command - http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/keytool.html
Openssl command - http://www.openssl.org/docs/apps/req.html#EXAMPLES
Reference:
https://www.owasp.org/images/e/e7/Thick_Client_(In)Security_-_Neelay_S_Shah_-_Mar_24.pdf
Issues with Client-Side Validation
Client-side validation can be easily bypassed. For example, a malicious user could disable the client-side script routines by disabling JavaScript. Users may also construct their own form posts using custom HTML, or using an HTTP proxy to modify form posts. Reliance on client-side validation can lead to code injection vulnerabilities (such as cross site scripting or SQL injection). If you use client-side validation to enforce application logic, such as the cost of items in an online store, the logic can be circumvented resulting in vulnerabilities ranging from application defacement to theft of merchandise or money.
How to ensure all inputs passed to Database is validated ?
Follow these steps to ensure that all input passed to database is validated:
1.Identify all sources of input to the database. An application can have various sources of input. Each of these sources is an entry point to your application and can potentially be used to break your application's security model. Determine all sources of input that are eventually pushed to the database.
Potential sources of input in a web application typically include:
◦URL based parameters
◦Form based parameters
◦Hidden fields
◦Cookies
◦HTTP headers
◦Data stored on the local filesystem
◦Database
◦Other related services
2.Verify that validators have been used to check the input. Check that a content-specific validator has been placed at each entry point.
Each database input source should have a data validation routine associated with it. Ideally the validation will occur as soon as the input reaches your application. Shared validation routines are better than creating many spread throughout your code base, so check for consolidation of routines to aid testing. If a database input source does not have a validation routine associated with it, flag it for fixing.
3.Ensure that type-safe parameters and stored procedures are used. Check that stored procedures and parametrized queries have been implemented instead of using the input values directly in constructing dynamic SQL queries as the latter is prone to SQL injection.
4.Ensure that database entry paths have been audited. Get a 3rd party reviewer to verify that all the database input paths have been identified and that validators have been correctly implemented for all entry points.
1.Identify all sources of input to the database. An application can have various sources of input. Each of these sources is an entry point to your application and can potentially be used to break your application's security model. Determine all sources of input that are eventually pushed to the database.
Potential sources of input in a web application typically include:
◦URL based parameters
◦Form based parameters
◦Hidden fields
◦Cookies
◦HTTP headers
◦Data stored on the local filesystem
◦Database
◦Other related services
2.Verify that validators have been used to check the input. Check that a content-specific validator has been placed at each entry point.
Each database input source should have a data validation routine associated with it. Ideally the validation will occur as soon as the input reaches your application. Shared validation routines are better than creating many spread throughout your code base, so check for consolidation of routines to aid testing. If a database input source does not have a validation routine associated with it, flag it for fixing.
3.Ensure that type-safe parameters and stored procedures are used. Check that stored procedures and parametrized queries have been implemented instead of using the input values directly in constructing dynamic SQL queries as the latter is prone to SQL injection.
4.Ensure that database entry paths have been audited. Get a 3rd party reviewer to verify that all the database input paths have been identified and that validators have been correctly implemented for all entry points.
Sony's massive data breach - 77 million customer accounts was stolen
Sony's PlayStation Network, a service that produces an estimated $500 million in annual revenues, provides access to online games, movies and TV shows. Nine out of 10 of PlayStation's users are based in the United States or Europe.
Sony said it had encrypted all credit card numbers, which would make it extremely difficult for hackers to access that data. But criminals might use other personal information that was not encrypted to launch scams.
With birthdates, email addresses and home addresses, hackers can launch spear "phishing" attacks that are targeted at those individuals.
Spear phishing refers to attacks that are customised to each individual target. Hackers draft emails that contain enough personal information to persuade the victim to let down their defenses, which can be enough to get them to click on a link that downloads malicious software onto their personal computer.
Sony said it had encrypted all credit card numbers, which would make it extremely difficult for hackers to access that data. But criminals might use other personal information that was not encrypted to launch scams.
With birthdates, email addresses and home addresses, hackers can launch spear "phishing" attacks that are targeted at those individuals.
Spear phishing refers to attacks that are customised to each individual target. Hackers draft emails that contain enough personal information to persuade the victim to let down their defenses, which can be enough to get them to click on a link that downloads malicious software onto their personal computer.
Chip based credit & debit cards as against the more commonly used magnetic strip ones
Reserve Bank of India (RBI) last week suggested the industry shifts to chip-based cards as against the more commonly used magnetic strip ones.
Chip-based cards come with encrypted information, which makes then safer. But, the apex bank wants new credit and debit cards to provide greater security by asking for a second-level authentication by way of a personal identification number (PIN ).
Currently, all transaction data from the PoS terminals or automated teller machines (ATMs) to the host system are sent in a clear text format. The transaction data travels through public-switched telephone networks and General Packet Radio Service (GPRS). Any data compromise, due to wire tapping at the merchant establishment or during the communication carriage can lead to fraud. Fraudsters who get hold of a card can copy the information in case of magnetic stripe cards. However, this is not possible with chip-based ones.
More details available at : chip-based-cards-will-cutriskfraud-when-you-go-shopping
Chip-based cards come with encrypted information, which makes then safer. But, the apex bank wants new credit and debit cards to provide greater security by asking for a second-level authentication by way of a personal identification number (PIN ).
Currently, all transaction data from the PoS terminals or automated teller machines (ATMs) to the host system are sent in a clear text format. The transaction data travels through public-switched telephone networks and General Packet Radio Service (GPRS). Any data compromise, due to wire tapping at the merchant establishment or during the communication carriage can lead to fraud. Fraudsters who get hold of a card can copy the information in case of magnetic stripe cards. However, this is not possible with chip-based ones.
More details available at : chip-based-cards-will-cutriskfraud-when-you-go-shopping
Wednesday, April 14, 2010
Secure simply by SD3 way!
There is a saying in English “Old habits die harder” and there is a riddle around it
I have one, you have one.
If you remove the first letter, a bit remains.
If you remove the second, bit still remains.
After much trying, you might be able to remove the third one also, but it remains.
It dies hard!
What is it?
Here is the answer for above riddle :
If you remove the first letter “h” from the word “Habit” , still a-bit remains, further if you remove letter from a-bit, still ‘bit’ remains and unfortunately after you remove letter ‘b’ as well, still ‘it’ remains. What is the moral of the story? Habits do not die easily. They linger on and on….
I was wondering whether it is true for “Software developers” . Yes! It is! The evidence to support my argument is the number of security issues I find in several applications till date.
Clear text connection strings, Poor exception handling, un-sanitized user inputs , dynamic SQL and poor configuration issues and many more…and it’s all about poor habits [practices]. Can we do something about it is the problem question?
Why not? Inculcate good habits to erase the bad habits. Slowly over a period of time new habits superimpose themselves and take a charge.
SD3 is the Mantra to follow defense in depth principles. Developers have to follow the principles of SD3 to reduce security vulnerabilities in their applications.
SD 3 is Microsoft’s defense in depth strategy which stands for Secure by design, secure by default and secure in deployment.
Secure by Design: This means that developers follow secure coding best practices and implement security features in their applications to overcome vulnerabilities.
This principle consists of using security features like Authorization, Authentication, Auditing and logging, usage of least privilege account and cryptography etc.
Many designers and developers at the end just sprinkle few security features in their applications. Secure by design does not advocate that way.
Secure by design means blending security into your applications. It involves due consideration to security right from the design stage of your application and weaving security features into every aspect of application development process.
For Ex: If I know that my application handles sensitive data or information, I would like to encrypt the data and protect it from theft and tampering. I give due consideration to use cryptography in my application right at the design stage.
Secure by Default: This simply means that end users install applications without altering the default settings and therefore requires these users specifically select features that might not be used or that might reduce security.
Many users do not change the default settings after installation. Why to bother them by asking them to disable unwanted features to reduce the attack surface? Security should be by default. If a feature is specifically required by a user she will enable as per her choice and with knowledge of consequences in case of security breach.
For Ex: Users are prompted to select optional components during the setup procedure and have the option to add those components later by re-running setup.
Secure in deployment The applications can be maintained securely after deployment by updating with security patches, monitoring for attacks, and by auditing for malicious users and content.
This involves having a process to identify newly discovered security vulnerabilities and ability to patch them regularly to remove those vulnerabilities. Also involves taking data – backups so that you can restore to normal in the event of a compromise, monitoring events at regular intervals and check for intrusions.
For Ex: In the event of application failure or errors, a system should be in place so that users should be shown only generic error information and those events should be logged so that administrators can help resolve the issues.
So dear developers conform to SD3 to develop secure applications and advocate security best practices to your fellow colleagues.
I have one, you have one.
If you remove the first letter, a bit remains.
If you remove the second, bit still remains.
After much trying, you might be able to remove the third one also, but it remains.
It dies hard!
What is it?
Here is the answer for above riddle :
If you remove the first letter “h” from the word “Habit” , still a-bit remains, further if you remove letter from a-bit, still ‘bit’ remains and unfortunately after you remove letter ‘b’ as well, still ‘it’ remains. What is the moral of the story? Habits do not die easily. They linger on and on….
I was wondering whether it is true for “Software developers” . Yes! It is! The evidence to support my argument is the number of security issues I find in several applications till date.
Clear text connection strings, Poor exception handling, un-sanitized user inputs , dynamic SQL and poor configuration issues and many more…and it’s all about poor habits [practices]. Can we do something about it is the problem question?
Why not? Inculcate good habits to erase the bad habits. Slowly over a period of time new habits superimpose themselves and take a charge.
SD3 is the Mantra to follow defense in depth principles. Developers have to follow the principles of SD3 to reduce security vulnerabilities in their applications.
SD 3 is Microsoft’s defense in depth strategy which stands for Secure by design, secure by default and secure in deployment.
Secure by Design: This means that developers follow secure coding best practices and implement security features in their applications to overcome vulnerabilities.
This principle consists of using security features like Authorization, Authentication, Auditing and logging, usage of least privilege account and cryptography etc.
Many designers and developers at the end just sprinkle few security features in their applications. Secure by design does not advocate that way.
Secure by design means blending security into your applications. It involves due consideration to security right from the design stage of your application and weaving security features into every aspect of application development process.
For Ex: If I know that my application handles sensitive data or information, I would like to encrypt the data and protect it from theft and tampering. I give due consideration to use cryptography in my application right at the design stage.
Secure by Default: This simply means that end users install applications without altering the default settings and therefore requires these users specifically select features that might not be used or that might reduce security.
Many users do not change the default settings after installation. Why to bother them by asking them to disable unwanted features to reduce the attack surface? Security should be by default. If a feature is specifically required by a user she will enable as per her choice and with knowledge of consequences in case of security breach.
For Ex: Users are prompted to select optional components during the setup procedure and have the option to add those components later by re-running setup.
Secure in deployment The applications can be maintained securely after deployment by updating with security patches, monitoring for attacks, and by auditing for malicious users and content.
This involves having a process to identify newly discovered security vulnerabilities and ability to patch them regularly to remove those vulnerabilities. Also involves taking data – backups so that you can restore to normal in the event of a compromise, monitoring events at regular intervals and check for intrusions.
For Ex: In the event of application failure or errors, a system should be in place so that users should be shown only generic error information and those events should be logged so that administrators can help resolve the issues.
So dear developers conform to SD3 to develop secure applications and advocate security best practices to your fellow colleagues.
Subscribe to:
Posts (Atom)
