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
Subscribe to:
Posts (Atom)
