Secure Dose

Monday, 8 June 2015

Secure Web Application PART - II

In case you haven't read PART - I read it here
Lets continue..

Common attack vectors:

@Attack Vectors are the "scope" of an attacker/malicious user to attack on the application and exploit the vulnerabilities discovered by him.

The Following are some common attack vectors where an attacker can attack and gain a particular level of access to your web application or can make it unavailable to other users so that they cannot access the resources and features provided by this web app.

1.  User Input Fields

2.  URL & Parameter Manipulation
3.  Information Disclosure (http header/server side error/etc..)
4.  @Authorization
5.  @Authentication
6.  Insecure Data Storage
7.  Insecure File Upload
8.  Pivilage Elevation
9.  Dos/DDos
10. Business Logics
11. Insecure Hosted Applications
12. Social Engineering
The following image includes them:



Check your existing web security:

Following are some of the question/check list to answer and have a look into to check whether your existing web application is having basic security implemented?
It can also be used as a checklist to develop a secured web application.

Infrastructure Considerations:
  • Does the network provide secure communication?
  • Does your deployment topology include an internal ‍ all?
  • Does your deployment topology include a remote application server?
  • What restrictions does infrastructure security impose?
Input Validation:
  • How are you ‍validating user inputs?
  • What do you do with the input?
Authorization:
  • How do you authorize end users?
  • How do you authorize the application in the database?
  • How do you restrict access to system-level resources?
Authentication:
  • Do you separate public and restricted access?
  • How do you authenticate the Application?
  • How do you authenticate with the database?
  • Do you enforce strong account management practices?
Sensitive Data:
  • Do you store secrets?
  • How do you store sensitive data?
  • Do you pass sensitive data over the network?
  • Do you log sensitive data?
Cryptography:
  • Why do you use particular algorithms?
  • How do you secure encryption keys?
  • Are you revealing your logic's unknowingly?
Parameter Manipulation:
  • Do you validate all input parameters?
  • Do you pass sensitive data in parameters?
  • Do you use HTTP header data for security?
Exception Management:
  • Are you revealing too much of information to the user?
  • Sure you have made a check to all the corners?
  • Are you exceptions default?
Monitoring Fails:
  • Do you log fail attempts?
  • Where are your logs stored?
  • Are they open to public?
  • Are your log files secure?
Using these check list and looking after it will fill up the basic gaps to secure your web application. Also do mind, that in maximum cases the insider is responsible behind the attack on an organization. 

So #OperationalSecurity is also to be taken care of. 


Web Application testing methodologies:

  • Where to start?
  • How to test a web application?
  • What are the per-requisites? 
  • How to finding vulnerabilities?
  • How to report?
  • Any standards?
  • Any drafts or documentation? 
  • How to mitigate risk?
To answer these questions, there are open communities where experts from around the world contribute.

Lets checkout few of them:
1.   Owasp (www.owasp.org)
2.   OSSTMM (www.isecom.org/research/osstmm.html)
3.   NIST (csrc.nist.gov)
4.   PTES (www.pentest-standard.org)
5.   ISACA (www.isaca.org)
6.   AppSec Labs Methodologies (www.appsec-labs.com) etc...

Why testing methodologies?
Testing with a particular method is known to be efficient because:
  • It helps if you have missed out something.
  • Defines the way to approach risk based testing
  • Systematic way to conduct test.
  • Proper report generation.
Conclusion
Having a checklist help developing a secured web application though, we never consider that an application is 100% secure but having this checklist we can say that we took security measures. 
Following the standards helps a lot with security as it shows the direction. From where to start till where to end. Well, security is a never ending task! :D

Tuesday, 2 June 2015

Secure Web Application Part - I


Introduction:

There are so awesome web developers with new idea's, new initiatives and startups. They sometimes fail what they claim. They claim to secure the files and have pretty good privacy features.There is always a need to have a security check simultaneously so that no re-engineering is required to implement necessary securities measures.The article is specifically for newbies, developers and security guys to have a check list or note while they develop or test a web application.Today we will be talking about how a secured web architecture and some security checks you must know, what are the things to be taken care of and what all things to implement, server side and at application-level.


A head start:

Typical Web Application Working:
So 1st of all we must know how a normal application exists and how it actually works along side with the server.An Application is firstly hosted on a web server or an application server. There is a difference. The web server accepts the request and accordingly responds. We have clients which we consider a web "browser" because these are used to send request to a website or a web application to access the feature provided by it. So we have browser as our client which connects to the internet (1) and then to the web server.That is the 1st request and with that css and other UI modules are loaded (2a)(2b). 




Now the web server interacts (3) with the web application server having web applications and processing stuff where it works and loads modules to provide feature to the client request along with that many times a database is needed so it also sends the request to the database server (4) and the data. Application server receives the data from the database and then it is again used in the response for the client as (5) with all the reverse process.

This is the working of web application which is very important to know to secure it.


What makes these web application vulnerable?
For most of the web developers, they configure SSL , Firewall, and Host Security to secure their web application. The case is mostly here in India but that should not be the case. These things only secure network and host but not the web application.
The reason why applications are vuln is:
  • Awareness at the 1st point.
  • Security testing session late in the Development Life Cycle.
  • Bad configurations.
  • Logical Issue's.
  • Leakage of valuable information.
  • Services running which are not in use.
  • Not changing default username and password
  • Revealing information on error such as stack traces.
  • Guessing user id and gaining direct access to the account and many other..
These are some of the common things to be taken care of which leads to compromise a web application. Lets further talk about the secured web.


A Secured web application:
A secured web application working consist of many parameters like validation both server side and at application-level, url manipulation, authorization, authentication, differing user level access and administration level access, encryption, securing sensitive data etc..
Here lets study about a secured web architecture that how a secure application should look like theoretically.

An application should have a WAF(Web Application Firewall) to prevent url manipulation(Not allowing special characters), protecting secure data and files(Restricting to access the directory), preventing session hijacking and replay attacks, etc.. waf's like mod_security,naxi, ironbee, csf and few more along with HAProxy for load balancing be configured to protect it as the 1st step.

Next is security to implement on web server like validating the user inputs, providing secure communication(SSL), native security configs, handling http error codes and other exceptions. 


On an application server logging activities and fails, authenticating and authorizing the requesting users identities, preventing the data and filtering the user inputs here. 
Having a daily track on auditing the logs is a very good practices to check out the fail attempts or any kind of server issues or finding a user behaving unexpectedly and possible malicious user.
Database needs to store sensitive information like passwords, cvv, etc. They can be stored with md5 hash and SHA etc.

Conclusion:
Analyzing and reviewing application at the initial level while development becomes efficient because later re-engineering may required.
Secured web application when applied help reducing a certain level of risk. 
If the application is already built, it will still help to fix the vulnerabilities and mind security in future design. 

Read out the 2nd Part..

 
biz.