Posts on Sep 2017

What is Blockchain Technology?

“Bitcoin is just one example of something that uses a blockchain. Cryptocurrencies are just one example of decentralized technologies. And now that the Internet is big enough and diverse enough, I think we will see different flavors of decentralized technologies and blockchains. I think decentralized networks will be the next huge wave in technology. The blockchain allows our smart devices to speak to each other better and faster.” Melanie Swan, author of Blockchain: Blueprint for a New Economy by Swan, Melanie (2015) Paperback

Blockchain is now making the biggest revolution in the finance industry. As a technologist, we should evaluate and apply the concept of Blockchain without thinking Cryptocurrency. It can unveil many possibilities and can lead to innovations. Cryptocurrency is becoming a distraction to the possibilities of blockchain as people have started using terminologies vice-versa.

What is blockchain technology and why it is safe?

Blockchain provides a protocol for building a shared, replicated and distributed online ledger network. Each participant in this blockchain network maintains their own copy of that database, or collection of organized information.

If you simply put,  blockchain is made up of a series of blocks of data that are securely tied together. Since all records are connected to each other, they are entrenched. It is impossible to modify or alter a previous record without changing the copy of every participant in the blockchain.

There are some disruptions too!

Contracts, transactions, and ledger are the defining structures which set the boundaries of our economic, legal and political systems. Today these involve people and corruption. With blockchain, contracts can be embedded in digital codes, stored in shared databases, protected from tampering.

Blockchain may be disruptive, but the question is if it’s too disruptive for its own good.

Although blockchain is one of the hottest and intriguing technologies currently in the market but it comes with its own challenges. Many business leaders and industrialists are skeptical about blockchain.

Let’s see what are those skeptics:

  • It will be hard for established business in the industry where blockchain will push uncomfortable transparency which can lead to price corrections and change in business models. It can be so much disruption that it can lead to the foundation of new technologies.
  • Adoption problem of Blockchain technology
  • Time-consuming: Blockchain-based transactions can only complete when all parties update their respective ledgers – which is a very time-consuming process.

Eight reasons to be skeptical about blockchain.

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.

InsurTech: Present and Future of Insurance Technology

Insurers need to spin the technology that offers their customers with more efficient, optimized and relevant policies. The ones that could be customized could be fed with data from a wearable/mobile device or the ones that are applicable for just an hour. With such customer focus initiatives, they yet need to achieve core business objectives like price and operational efficiency and compliance to stringent regulations. Could the Insurtech meet up the expectations? Could technology lend a helping hand? Let’s explore how the insurance vertical is evolving with the latest technology and what its future is –

The Present of InsurTech

The insurance firms are under immense pressure of reorganizing their house – customized policies, risk mitigation strategies, real-time analytics, instant claim settlement, sensors, drones and augmented reality (AR) apps are playing a significant role. So, what are the technologies adopted by the firms? Let’s take a closer look –

Robo-Advisory Services

Robo-Advisors have seen a broad adoption across insurance sectors. Unlike olden days when hiring a financial advisor was a dream for many individuals, with Robo-advisors people of the low-income group could use DIY advisory for their financial portfolio. Should you opt for all critical disease cover or only a few? Should buying an integrated policy be beneficial or an individual one is some of the questions that could be answered via Robo-Advisory Services.

Policies via Sensors, Detectors, and Telematics

Sensors, Detectors connected via the internet could send early signals of smoke/radiations to the rescue services, helping in minimizing the damages. Also, Telematics like monitoring automobile speed, the behavior of a rash driver could assist in making a clear judgment of claim policies for individuals and insurance firm. Hence while IoTs and interconnected network could be a boom in offering customized policies, these minuscule are taking insurance services to the next step.

The Future of InsurTech

Could technologies like Blockchain, Augmented Reality, Virtual Reality change the world sees insurance sector? Would they bring in the exotic flavors of policies? Only time can tell, for now, let’s explore how these technologies could be handy in insurance sector?

Blockchain

A distributed ledger technology has the potential to ease out fraud detection and risk prevention as per a report from EY. The report also highlights that blockchain is efficient in establishing transparent and customer focussed claims building trust and loyalty for the insurance firms.

Augmented or Virtual Reality

Just imagine driving in stormy weather, an AR app helps you define the road/lane border so that you do not bombard a tree or a car in your parallel path. Or how about a 3D modeling and simulations help customers in making insurance claims easier and faster? Or how about before you go for the home insurance a simulation helps you pinpoint all the areas under insurance rather than reading the lengthy document? It all is a possibility with AR and VR technologies.

With the evolution of technologies, the secret is to be adaptable to change. @Mantra Labs we believe in this, and hence one of our esteemed clients Religare is using our InsurTech solutions in Post-sale, pre-claim, post-claim and renewal processes. It helps in providing customers with transparent and intuitive services that is robust and secured for businesses. A win-win for all.

Reference Links:

https://assets.kpmg.com/content/dam/kpmg/xx/pdf/2016/10/how-augmented-and-virtual-reality-changing-insurance-landscape.pdf

https://www.realexpayments.com/blog/augmented-reality-insurance-businesses/