Secure Dose

Monday, 8 June 2015

Secure Web Application PART - II

In case you haven't read PART - I read it hereLets 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 Fields2. URL & Parameter Manipulation3. Information Disclosure (http header/server side error/etc..)4. @Authorization5. @Authentication6. Insecure Data Storage7. Insecure File Upload8. Pivilage Elevation9. Dos/DDos10. Business Logics11. Insecure Hosted Applications12. Social EngineeringThe 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.

ConclusionHaving 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

The Blog is completly related to websec and sometimes other branches of Information Security. It focus on theory and practical both with some resource section provided where I share my presentation pdf where I recently give my talk. Have a good read and suggestions are always welcome.