Use of svn in web application

Subversion manages files and directories, and the changes made to them, over time. This allows you to recover older versions of your data or examine the history of how your data changed. In this regard, many people think of a version control system as a sort of “time machine.”

Managing web applications in SVN is tricky for some reasons:

When using revision control, a programmer is always working on a ‘working copy’ of the project. In traditional software engineering, this copy is somewhere on the his machine, as it’s a stand-alone application. In web development, however, we’re talking about webspace. Should every developer have a PHP environment on his machine then? Shouldn’t all programmers work on the exact same server configuration? What about Windows and Mac users? Web Application Development India

This means the working copies should be best on one webserver, along with an SVN client. Thus, we need some interface (the most simple one being SSH) to access it. Maybe a rich web client would be even better.

The application needs to be deployed to a live webspace. This might happen quite often and should be as painless as possible.

Version Control Terminologies

Let us start by discussing some of the terms that we will be using in this tutorial.

Repository: A repository is the heart of any version control system. It is the central place where developers store all their work. Repository not only stores files but also the history. Repository is accessed over a network, acting as a server and version control tool acting as a client. Clients can connect to the repository, and then they can store/retrieve their changes to/from repository. By storing changes, a client makes these changes available to other people and by retrieving changes, a client takes other people’s changes as a working copy.

Trunk: The trunk is a directory where all the main development happens and is usually checked out by developers to work on the project.

Tags : The tags directory is used to store named snapshots of the project. Tag operation allows to give descriptive and memorable names to specific version in the repository.

Branches: Branch operation is used to create another line of development. It is useful when you want your development process to fork off into two different directions. For example, when you release version 5.0, you might want to create a branch so that development of 6.0 features can be kept separate from 5.0 bug-fixes.

Working copy: Working copy is a snapshot of the repository. The repository is shared by all the teams, but people do not modify it directly. Instead each developer checks out the working copy. The working copy is a private workplace where developers can do their work remaining isolated from the rest of the team.

Commit changes: Commit is a process of storing changes from private workplace to central server. After commit, changes are made available to all the team. Other developers can retrieve these changes by updating their working copy. Commit is an atomic operation. Either the whole commit succeeds or is rolled back. Users never see half finished commit.

To know more about our web and mobile development service visit http://evincetech.com.
For more information, please contact us with the specifications for your project. You can email our sales team at info@evincetech.com, also you can call us at following numbers.
India: (+91) 44 42170775, (+91) 91766 40375
USA [Toll Free]: 866 220 6565

Web application vulnerable and prevention

SQL Injection :

SQL injection is a technique where malicious users can inject SQL commands into an SQL statement, via web page input.A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database.

Any business affected by an SQL Injection would need to take steps quickly to rectify the issue. The loss of personal data, financial information and other aspects can cause a great deal to harm a company’s reputation. That is why it’s crucial to be forewarned and protected against such threats before they occur.

To Avoid SQL Injection:

SQL statements that are sent to and parsed by the database server separately from any parameters. This way it is impossible for an attacker to inject malicious SQL. Website Development India

Using PDO and MySQLi

1) Parametrized queries using bound, typed parameters.
2) Careful use of parametrized stored procedures.

Broken Authentication & Session Management

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

OWASP lists seven reasons an application may be vulnerable:

User authentication credentials aren’t protected when stored using hashing or encryption.
Credentials can be guessed or overwritten through weak account management functions.
Session IDs are exposed in the URL.
Session IDs are vulnerable to session fixation attacks.
Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on tokens, aren’t properly invalidated during logout.
Session IDs aren’t rotated after successful login.
Passwords, session IDs and other credentials are sent over unencrypted connections.

To prevent  Broken Authentication & Session Management

To prevent these types of vulnerabilities from occurring in your application, developers should first ensure that SSL is used for all authenticated parts of the application. In addition, verify that all credentials are stored in a hashed form.

1) Avoid cookiesless session
2) Look into IP Checking
3) Use SSl
4) Expire session early and often
5) Double- check passwords on certain activities

XSS (Cross Site Scripting)

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

When information is sent to web service providers such as banks or online stores, webmasters, or website owners, an attacker can interrupt the transfer process and extract this valuable information. This can all be done seamlessly without either the website owner/provider or the client having knowledge of the attack.

Data loss, misleading content and other issues cause massive amounts of damage to a company’s reputation and can severely stain the brand if left untreated.

To prevent  XSS (Cross Site Scripting)

Data Validation
Data Sanitization
Output Escaping

  • Never pass data from untrusted origins into output without either escaping or sanitising it.
  • Never forget to validate data arriving from an untrusted origin using relevant rules for the context it’s used in.
  • Remember that anything not explicitly defined in source code has an untrusted origin.
  • Remember that htmlentities() is incompatible with XML, including HTML5′s XML serialisation – use htmlspecialchars().
  • Always include ENT_QUOTES, ENT_SUBSTITUTE and a valid character encoding when calling htmlspecialchars().
  • Never use htmlspecialchars() as the primary means of escaping Javascript, CSS or URL parts.
  • Never use json_encode() to escape Javascript strings unless using PHP 5.3 and RTFM.
  • Use rawurlencode() to escape strings being inserted into URLs and then HTML escape the entire URL.
  • Never ever pass escaped or sanitised data from untrusted origins into a Javascript execution context: a string later executed as Javascript.
  • Validate all complete URLs if constructed from untrusted data.
  • Never validate URLs using filter_var(). It doesn’t work and allows Javascript and Data URIs through.
  • Never include resources loaded over unsecured HTTP on a page loaded over HTTPS.
  • Sanitise raw HTML from untrusted origins using HTMLPurifier before injecting it into ouput.
  • Sanitise the output of Markdown, BBCode and other HTML replacements using HTMLPurifier before injecting it into output.
  • Remember that HTMLPurifier is the only HTML sanitiser worth using.
  • Adopt the Content Security Policy (CSP) header and abandon the use of inline CSS and Javascript where feasible.
  • Always transmit, with content, a valid Content-Type header referencing a valid character encoding.
  • Ensure that cookies for use solely by the server are marked HttpOnly.
  • Ensure that cookies which must only be transmitted over HTTPS are marked Secure.
  • Always review dependencies and other third party code for potential XSS vulnerabilities and vectors.

 

To know more about our web and mobile development service visit http://evincetech.com.
For more information, please contact us with the specifications for your project. You can email our sales team at info@evincetech.com, also you can call us at following numbers.
India: (+91) 44 42170775, (+91) 91766 40375
USA [Toll Free]: 866 220 6565