CodeChef4U

Code recipes with master chefs.

Codechef4u is a community for computer professionals,by computer professionals,just like you; who loves sharing and helping each others,Join them
Share your post

Interfaces in TypeScript

16. February 2018 Nagnath M. Kendre Scripts, Typescript, Articles (0)
Interfaces provide the ability to name and parameterize object types and to compose existing named object types into new ones.

Interfaces have no run-time representation—they are purely a compile-time construct. Interfaces are particularly useful for documenting and validating the required shape of properties, objects passed as parameters, and objects returned from functions.

Here we use an interface that describes objects that have a firstName and lastName field. In TypeScript, two types are compatible if their internal structure is compatible. This allows us to implement an interface just by having the shape the interface requires, without an explicit implements clause.

Typescript interface code example:

interface IEmployee {
    firstName: string;
    lastName: string;
}
 
function getFullName(person:
IEmployee) {
    return "Hello,
" + person.firstName + " " +
person.lastName;
}
 
var user = {
firstName: "Shourya", lastName: "Kendre" };
 
window.onload = () => {
    var elFullNameName =
document.getElementById('lblFullNameName');
    elFullNameName.innerHTML = getFullName(user);  
};


HTML code:

<html lang="en">
<head>
    <meta charset="utf-8" />
    <title>TypeScript
HTML App</title>
    <link rel="stylesheet" href="app.css" type="text/css" />
    <script src="InterfaceExample.js"></script>
</head>
<body>
    <h1>TypeScript
HTML App</h1>
<label id="lblFullNameName"></label>
</body>
</html>


Result Page:


धन्यवाद मित्रानो !!!


OWASP Top 10 Security Risks-2017

15. February 2018 Nagnath M. Kendre Web Security, Security, Articles (0)

I written around 7 web security and cyber security related articles, in this article i will summarize latest version OWSAP top 10 critical security risks.

What is OWASP?

The Open Web Application Security Project (OWASP), an online community, produces freely-available articles, methodologies, documentation, tools, and technologies in the field of Web application security.

How OWASP decides top 10 risks?

The OWASP Top 10 focuses on identifying the most serious web application

security vulnerabilities and risks for a different types companies and organizations.

For those risks OWASP team provides generic information about likelihood and technical impact using simple rating scheme, based in OWASP Risk RatingMethodology

The final version of the 2017 OWASP Top 10 was released on November 21, 2017 according to OWASP team following are the ten most critical web application security risks presently.


OWASP Top 10 year 2017

 A1: Injection
 A2: Broken Authentication
 A3: Sensitive Data Exposure
 A4: XML External Entities (XXE) [NEW]
 A5: Broken Access Control [Merged]
 A6: Security Misconfiguration
 A7: Cross-Site Scripting (XSS)
 A8: Insecure Deserialization [NEW]
 A9: Using Components with Known Vulnerabilities
 A10: Insufficient Logging & Monitoring [NEW]

OWASP team introduced three new critical security risks in 2017 version release I will explain those in short.

A4: XML External Entities (XXE)

Many older or poorly configured XML processors evaluate external entity references within XML documents.
External entities can be used to disclose internal files using the file URI handler,
internal file shares, internal port scanning, remote code execution, and denial of service attacks.

Prevention:

a. In must require case only use complex data formats such as JSON and serialization and deserialization else avoid it.

b. Upgrade XML dll, libraries those used like XML processors Update SOAP to latest version.

c. User server side while list approach for input validation, data sanitization, for xml document, headers and xml nodes.

d. Validate all external XML/XSL files.

e. Use tools like SAST to detect XXE and perform manual code review

d. According to OWASP the safest way to prevent XXE is always to disable DTDs (External Entities) completely.

For more details use OWASP prevention cheat sheet

https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet

A8: Insecure Deserialization

What is serialization and deserialization

To store and use for communication convert data into stream of bytes, deserialization is reverse process.

Insecure Deserialization

Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

Prevention:

a. Safest way is to avoid serialized data from untrusted users and untrusted sources.

b. Implement integral check such as digital signature

c. use strict type constraint when deserialization and serialization, for example allow only defined classes

d. code that prevents deserialization and serialization in low privileges environment

e. Log deserialization and serialization failures, exceptions and monitoring incoming and outgoing connectivity from containers and servers that deserialize and monitoring deserialization.

f. There are some language specific Guidelines and proper coding techniques for developers that prevent from this attack, I suggest developers and programmers to refer following cheat sheet documents from OWASP.

https://www.owasp.org/index.php/Deserialization_Cheat_Sheet

A10: Insufficient Logging & Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data.

Prevention:

a.  Log all login, access, validation failures with sufficient details, that details you can use to track identify suspicious or malicious accounts.

To maintain logs, use standard centralized log management system.

b.  Implement effective monitoring and alerting such that suspicious activities are detected and responded in timely fashion.

c. Requires audit and monitoring on high value transaction.

d. Adopt incident/failure plan and recovery plan for system.

e. Use proper notification and alerts for suspicious activities.


References: //www.owasp.org

 

धन्यवाद मित्रो !! 

Thanks Friends

 

Simple Rules to Prevent SQL Injections

21. January 2018 Nagnath M. Kendre SQL Server, Security, Articles (0)

Introduction

Previously I written around 7 computer security related articles (mostly on web security and cyber security), and this is my first article or post on RDBMS data or database application security.

In this article I will explain in short what are sql injections and simple rules to prevent sql injections, I want to say thanks to my friend Vaibhav Shringi (DB expert and IITian) for his help to prepare this post.

What is SQL injection?

SQL injection is a type of security exploit in which the attacker adds SQL code to a Web form input box or any other manner to gain access to resources or make changes to data.

How to Prevent SQL Injection Attacks? 

Simple Rules to Prevent SQL Injections

1. Sanitize the Input:

It's absolutely vital to sanitize user inputs to insure that they do not contain dangerous codes, whether to the SQL server or to HTML itself.

We should always attempt to allow only required characters approach not to stuff “Bad characters”

There is really no benefit in allowing characters that could not be valid, and rejecting them early - presumably with an error message - not only helps forestall SQL Injection, but also catches mere typos early rather than stores them into the database.

Better prevention: White List Input Validation

2. Escape/Quotesafe the input:

We can’t sanitize the inputs which allows special characters eg. “Bill O'Reilly” is a valid name.

Always use QUOTENAME() function in SQL statements if user input are required in In-line queries.

3. Use Bound Parameters:

Though quote-safing is a good mechanism, we're still in the area of "considering user input as SQL", and a much better approach exists: bound parameters, which are supported by essentially all database programming interfaces.

Example:

            PreparedStatement ps = connection.prepareStatement(
             "SELECT email FROM member WHERE name = ?");
            ps.setString(1, formField);
            ResultSet rs = ps.executeQuery();

 

This is probably the single most important step one can take to secure a web application.

 

4. Limit database permissions and segregate users:

The web application ought to use a database connection with the most limited rights possible: query-only access to the members table, and no access to any other table. If required can move to higher rights after successful login. 

It prevents unauthorized updates/delete/drop operations.
We should not use “SA” or same level rights’ users.

 5. Use stored procedures for database access:

Use stored procedures for performing access on the application's behalf, which can eliminate SQL entirely. By encapsulating the rules for a certain action - query, update, delete, etc. - into a single procedure, it can be tested and documented on a standalone basis and business rules enforced.

Example

DB SP:

      Create PROCEDURE [dbo].[ReadUserDetails]
               
-- Add the parameters for the stored procedure here
          @userName varchar(50)
         AS
         BEGIN
           SELECT * FROM [UserDetails] where userName= @userName
         END

 

C# code that’s use SP:

  public static DataTable ExecuteSelectCommand(string StoredProcedureName)
        {
            // SqlCommand cmd = null;
            var table = new DataTable();
                using (var con = new SqlConnection(GetConnectionString()))
                {
                    con.Open();
                    using (var cmd = new SqlCommand(StoredProcedureName, con))
                    {
                        cmd.CommandType = CommandType.StoredProcedure;
                        //cmd.CommandText = commandName;
                        SqlDataAdapter da = null;
                        using (da = new SqlDataAdapter(cmd))
                        {
                            da.Fill(table);
                        }
                    }
                }
            return table;
        }


6. Isolate the webserver:

Even having taken all these mitigation steps, it's nevertheless still possible to miss something and leave the server open to compromise.

Isolated webserver with limited network pinholes can assure limited access to other servers in case of full webserver control.

 

7. Configure error reporting:

The default error reporting for some frameworks includes developer debugging information, and this cannot be shown to outside users. Imagine how much easier a time it makes for an attacker if the full query is shown, pointing to the syntax error involved.

This information is useful to developers, but it should be restricted - if possible - to just internal users.



धन्यवाद मित्रो !! 

Thanks Friends