Showing posts with label App Security. Show all posts
Showing posts with label App Security. Show all posts

Friday, March 27, 2015

Web services - Part6


Webservices Security

Web Services use known protocols, ports, descriptors and methods to access and “expose” back-end components to the client side. This means that any Web service vulnerable to following and more:
  • SQL injections
  • Scripting exploits
  • Denial of Service attacks: an attacker does a small amount of work on a message that causes the target system to devote all its resources to a specific task so that it cannot provide any services to valid requests.
  • Message monitoring and copying
  • Message source spoofing: An attacker alters an original message by inserting, removing or modifying content created by the originator, and the faked message is then mistaken by the receiver as being the originator’s real intention. In addition, an attacker may also construct a new fake message to fool the receiver into believing it to have come from a valid sender.
  • Message (payload) manipulation ( changing send data – in transit)
  • Transmission of viruses (in message or as an attachment)
  • Transactional Attacks
  • Replay of message parts: an attacker replays parts of the captured message to the receiver with the aim of gaining access to an unauthorised system, or causing the receiver to take unnecessary action.

Web services security aspects includes Authentication, Authorization, Confidentiality/privacy, Integrity/non repudiation
·         Authentication – It’s verification of user identity which is verified based on the credentials provided by user
·         Authorization or Access Control - it is granting access to specific resources after authentication of user
·         Confidentiality/privacy - Keeping information secret. For example encrypting the content of send messages.
·         Integrity/non repudiation – it’s surety that a message remains unaltered during transit. Digital signature is used to validate the signature and provides non-repudiation.

There are two types of security requirements for web services, transport level (Secure Socket Layer) and application/message level.

Transport-level Security
SSL (Secure Socket Layer) or TLS (Transport Layer Security) is the most widely used transport-level data-communication protocol. It provide Authentication, Confidentiality (encrypted data exchanged), Message integrity (uncorrupted data) and Secure key exchange between client and server.

SSL provides a secure communication channel when data is on transit, however, when the data is not "in transit," the data is not protected. This means in multi-step transactions the environment vulnerable to attacks. (SSL provides point-to-point security, as opposed to end-to-end security.)

Message-level Security

Message level security is an application layer service and facilitates the protection of message data between applications. Message-level security is based on XML frameworks defining confidentiality, integrity, authenticity; message structure; trust management and federation. Message structure and message security are implemented by SOAP and its security extension, WS-Security. WS-Security defines how to attach XML Signature and XML Encryption headers to SOAP messages. In addition, WS-Security provides profiles for 5 security tokens: Username (with password digest), X.509 certificate, Kerberos ticket, Security Assertion Markup Language (SAML) assertion, and REL (rights markup) document.

Message level security is used in scenarios where application is designed to use mostly asynchronous queues. SOAP based services use Message Level Security. In message level security, security information is contained within the SOAP message, which allows security information to travel along with the message. For example, a portion of the message may be signed by a sender and encrypted for a particular receiver. In this case message can pass through multiple nodes before delivered to destination and encrypted part of message is opaque to these intermediate nodes. For this reason, message-level security is also referred as end-to-end security.



Saturday, November 22, 2014

How to find security vulnerabilities in JAVA application libraries using Dependency Check

A web-application is never finished. Even when no new features are being developed new vulnerabilities may be found in the frameworks used in the application requiring a patch or an upgrade.Java is a very popular programming language. Two key reasons for its popularity are security and the availability of a huge ecosystem of libraries and components. Since most Java applications make use of a wide range of libraries, which in turn have dependencies on other libraries, it is difficult to ensure the integrity of these applications from a security perspective.

The OWASP Top 10 represents a broad consensus on the most critical web application security flaws.They are dangerous because they will frequently allow attackers to completely take over your software, steal data, or prevent your software from working at all
those are :
1. Injection : Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. Injection flaws are easy to discover when examining code, but frequently hard to discover via testing. Scanners and fuzzers can help attackers find injection flaws.

2. Broken Authentication and Session Management (XSS) : Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.

3. Cross Site Scripting (XSS) : XSS is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content. There are two different types of XSS flaws: 1) Stored and 2)Reflected, and each of these can occur on the a) Serveror b) on the Client.
Detection of most Server XSS flaws is fairly easy via testing or code analysis. Client XSS is very difficult to identify.
4. Insecure Direct Object References : Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws. Code analysis quickly shows whether authorization is properly verified.
5. Security Misconfiguration : Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.
6. Sensitive Data Exposure : The most common flaw is simply not encrypting sensitive data. When crypto is employed, weak key generation and management, and weak algorithm usage is common, particularly weak password hashing techniques. Browser weaknesses are very common and easy to detect, but hard to exploit on a large scale. External attackers have difficulty detecting server side flaws due to limited access and they are also usually hard to exploit.
7. Missing Function Level Access Control : Applications do not always protect application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget.
Detecting such flaws is easy. The hardest part is identifying which pages (URLs) or functions exist to attack
8. Cross Site Request Forgery (CSRF) : CSRF takes advantage the fact that most web apps allow attackers to predict all the details of a particular action.
Because browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones.
Detection of CSRF flaws is fairly easy via penetration testing or code analysis. 
9. Using Components with Known Vulnerabilities : Virtually every application has these issues because most development teams don’t focus on ensuring their components/libraries are up to date. In many cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse.
10. Unvalidated Redirects and Forwards : Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page.
Detecting unchecked redirects is easy. Look for redirects where you can set the full URL. Unchecked forwards are harder, because they target internal pages.

Now we will see how to find out security vulnerabilities in JAVA application libraries using Dependency Check,
dependency-check-ant is an Ant Task that uses dependency-check-core to detect publicly disclosed vulnerabilities associated with the project's dependencies. The task will generate a report listing the dependency, any identified Common Platform Enumeration (CPE) identifiers, and the associated Common Vulnerability and Exposure (CVE) entries.
Currently Java and .NET dependencies are supported. support for Node.JS, client side JavaScript libraries, etc. is planned.
Steps to follow :
Step 1 : Download dependency-check-ant from bintray here
Step 2 : To install dependency-check-ant place the dependency-check-ant-1.2.6.jar into the lib directory of your Ant instalation directory. Once installed you can add the taskdef to you build.xml and add the task to a new or existing target:
<'taskdef name="dependency-check" classname="org.owasp.dependencycheck.taskdefs.DependencyCheckTask"/'>
<'taskdef name="dependency-check" classname="org.owasp.dependencycheck.taskdefs.DependencyCheckTask"'>
<'classpath path="[path]/[to]/dependency-check-ant-x.x.x.jar"/'>
<'/taskdef'>
Step 3 : If you do not want to install dependency-check-ant into your ant’s lib directory when you define the task def you must add the classpath to the taskdef:
Step 4 : If you are behind proxy set proxy settings in you ant script as :
<'setproxy proxyhost="proxyIP/IURL" proxyport="proxyPort" /'>
That's it run you script to get the report
It is important to understand that the first time this task is executed it may take 20 minutes or more as it downloads and processes the data from the National Vulnerability Database (NVD) hosted by NIST: https://nvd.nist.gov

Source : www.owasp.org


Sunday, November 2, 2014

How to Scan Security Vulnerabilities in JavaScript Library using SecureJs

Javascript has been extensively used for several years ever since it was first developed by Netscape in 1995. It has virtually revolutionized the way the Internet and websites work by adding functionality that is lightweight yet feature-filled. Ad servers use javascript to display ads on websites, ads are virtually bread and butter to the website publisher and is thus responsible to several successful, established and useful websites. Apart from ads Javascript is also used to add graphical effects as well as several other functions to websites.
However, Javascript has been responsible for several security vulnerabilities over the years.
Securing client-side JavaScript is a problem that has started receiving attention. Third-party JavaScript issues from widgets, embedded code and JavaScript libraries are some of the vulnerable aspects of JavaScript that see active exploitation.
JavaScript security issues can be divided into three broad categories:
1.  DOM-based cross-site scripting (XSS) :
XSS is usually the result of insecurely written server-side code, DOM-based XSS is a kind of XSS occurring entirely on the client-side.
2.  Cross-domain information leakage : JavaScript has cross-domain functionality that allows sites to load multiple objects from various sources (widgets or iframes, among others). Until recently, JavaScript had restrictions on accessing/sending data to other domains. However, HTML5 has increased the level of cross-domain access that JavaScript enjoys with the cross-domain XML request function.

3.  Client-side logic and data storage : Initially, JavaScript performance and capabilities were very limited, receiving no significant focus from browser developers for improving performance. As JavaScript engines get faster with iterations of browser release, it is possible to perform substantial processing on the client-side.With HTML5, client-side storage mechanisms have gone beyond the cookie with newer options such as localStorage, Web SQL and IndexDB. Storage of sensitive data on the client side using these mechanisms fosters a huge security risk, bigger than cookies ever posed.

There are plenty of open source tools available SecureJs is one of them, let's see step by step how to scan your JavaScript libraries with SecureJs.

Step 1: Installing NodeJs : Download the Node.js source code from http://nodejs.org/download/ and install it in your system.

Step 2: Installing npm : npm (Node Package Manager) is the default package manager for Node.js. As of Node.js version 0.6.3, npm is bundled and installed automatically with the environment. npm runs through the command line and manages dependencies for an application. for Windows You can download a zip file from https://npmjs.org/dist/, and unpack it in the same folder where node.exe lives( Inside Program Files folder ).

Atep 3: Open Command Prompt and Install Retire JS using command "npm install -g retire" your Command Promt display will be like this :

C:\Users\satyendra.jaiswal\AppData\Roaming\npm\retire -> C:\Users\satyendra.jaiswal\AppData\Roaming\npm\node_modules\retire\b
in\retire
retire@0.3.1 C:\Users\satyendra.jaiswal\AppData\Roaming\npm\node_modules\retire
├── commander@2.0.0
├── underscore@1.4.4
├── walkdir@0.0.7
├── request@2.40.0 (forever-agent@0.5.2, oauth-sign@0.3.0, json-stringify-safe@5.0.0, aws-sign2@0.5.0, stringstream@0.0.4, tu
nnel-agent@0.4.0, qs@1.0.2, node-uuid@1.4.1, mime-types@1.0.2, http-signature@0.10.0, hawk@1.1.1, tough-cookie@0.12.1, form-d
ata@0.1.4)
└── read-installed@0.2.5 (graceful-fs@2.0.3, slide@1.1.6, semver@2.3.2, read-package-json@1.2.7)


Step 3 : Test if Retire is installed using retire command like : retire -h

Step 4 : Scan JS files of a specific folder using retire command : use retire -c to avoide local cache

If you are behind the proxy then use these steps :

Step 1: Set Proxy on command prompt :

npm config set registry http://registry.npmjs.org/
npm config set proxy http://myusername:mypassword@proxyIPorAddress:8080
npm config set https-proxy http://myusername:mypassword@proxyIPorAddress:8080
npm config set strict-ssl false
set HTTPS_PROXY=http://myusername:mypassword@proxyIPorAddress:8080
set HTTP_PROXY=http://myusername:mypassword@proxyIPorAddress:8080
export HTTPS_PROXY=http://myusername:mypassword@proxyIPorAddress:8080
export HTTP_PROXY=http://myusername:mypassword@proxyIPorAddress:8080
export http_proxy=http://myusername:mypassword@proxyIPorAddress:8080

Step 2: Install Retire :

npm --proxy http://myusername:mypassword@proxyIPorAddress:8080 --without-ssl --insecure -g install retire

Step 3 : Test if Retire is installed using retire command like : retire -h

Step 4 : Scan JS files of a specific folder using retire command

Total Pageviews