SQL Injection Problem in Hibernate Wth Parameter Binding
In this tutorial of SQL Injection and Parameter Binding in Hibernate we will discuss about SQL inject and its demerits and also describe Parameter binding, it means is way to bind parameter with SQL to use in the hibernate for particular criteria.
SQL INJECTION:
Injecting the value to the SQL statement. SQL injection refers to the act of someone inserting a MySQL statement to be run on your database without your knowledge. Injection usually occurs when you ask a user for input, like their name, and instead of a name they give you a MySQL statement that you will unknowingly run on your database.
Normal: " SELECT * FROM student WHERE studentName= 'sweety'"
Injection: "SELECT * FROM student WHERE studentName= '' +studentName
Injection: "SELECT * FROM student WHERE studentName= '' +studentName
PARAMETER BINDING:
A bind variable is a named placeholder (preceded by a colon) that is embedded in the query string in place of a literal. The actual value is substituted at runtime using the setParameter() method.
Without parameter binding, you have to concatenate the parameter String like this (bad code) :
Pass an unchecked value from user input to the database will raise security concern, because it can easy get hack by SQL injection. You have to avoid the above bad code and using parameter binding instead.
Hibernate parameter binding
There are two ways to parameter binding :
- Named parameters binding
- Positional parameters binding.
1. Named Parameters Binding:
This is the most common and user friendly way. It use colon followed by a parameter name (:example) to define a named parameter. See examples…
Example 1 – setParameter
The setParameter is smart enough to discover the parameter data type for you.
Example 2 – setString
You can use setString to tell Hibernate this parameter date type is String.Example 3 – setProperties
This feature is great ! You can pass an object into the parameter binding. Hibernate will automatic check the object’s properties and match with the colon parameter.
2. Positional parameters
It’s use question mark (?) to define a named parameter, and you have to set your parameter according to the position sequence. See example…
In Hibernate parameter binding, i would recommend always go for "Named parameters", as it’s more easy to maintain, and the compiled SQL statement can be reuse (if only bind parameters change) to increase the performance.
Backup and Restore Windows Drivers without any Software
You can backup all the device drivers installed on your current working system configuration without any software and also restore them if you format the operating system for any reason.
Do these simple steps:
Backup Drivers:
1. Run Windows command prompt with elevated admin permission. (Right on start button or Win+X key)
3. Run this command:
dism /online /export-driver /destination:C:\Users\pravi\Downloads\Driverbackup
4. Change the destination address as per your folder location.
6. Browse to the destination folder to check what you have. You can copy all those file to any other location.
Restore All Drivers:
1. Run command prompt with admin rights.
2. Execute this command:
Dism /online /Add-Driver /Driver:C:\Users\pravi\Downloads\Driverbackup/Recurse
3. This will restore all your drivers.
Restore Selective Drivers:
If you want to install only few of the drivers, you can manually install them by the traditional method.
Open the power menu (Right click on start button or Win+X keys). >> Device manager >> select the device you want to install drivers for >> Double click >> Drivers Tab >> Update Drivers >> Browse my computer for drivers software >> Next.
Windows will automatically search for correct drivers and install it.There are many softwares to do this task, but I think this is the best and easy one. What you think?
Working Of Garbage Collector
In Java, allocation and de-allocation of memory space for objects are done by the garbage collection process in an automated way by the JVM.
Java Memory Management
Java Memory Management, with its built-in garbage collection, is one of the language’s finest achievements. It allows developers to create new objects without worrying explicitly about memory allocation and deallocation, because the garbage collector automatically reclaims memory for reuse. This enables faster development with less boilerplate code, while eliminating memory leaks and other memory-related problems. At least in theory.
Ironically, Java garbage collection seems to work too well, creating and removing too many objects. Most memory-management issues are solved, but often at the cost of creating serious performance problems. Making garbage collection adaptable to all kinds of situations has led to a complex and hard-to-optimize system. In order to wrap your head around garbage collection, you need first to understand how memory management works in a Java Virtual Machine (JVM).
Java Garbage Collection GC Initiation
Being an automatic process, programmers need not initiate the garbage collection process explicitly in the code. System.gc() and Runtime.gc() are hooks to request the JVM to initiate the garbage collection process.
Though this request mechanism provides an opportunity for the programmer to initiate the process but the onus is on the JVM. It can choose to reject the request and so it is not guaranteed that these calls will do the garbage collection. This decision is taken by the JVM based on the eden space availability in heap memory. The JVM specification leaves this choice to the implementation and so these details are implementation specific.
Undoubtedly we know that the garbage collection process cannot be forced. I just found out a scenario when invoking System.gc() makes sense. Just go through this article to know about this corner case when System.gc() invocation is applicable.
Java Garbage Collection Process
Garbage collection is the process of reclaiming the unused memory space and making it available for the future instances.
Eden Space: When an instance is created, it is first stored in the eden space in young generation of heap memory area.
Survivor Space (S0 and S1): As part of the minor garbage collection cycle, objects that are live (which is still referenced) are moved to survivor space S0 from eden space. Similarly the garbage collector scans S0 and moves the live instances to S1.
Instances that are not live (dereferenced) are marked for garbage collection. Depending on the garbage collector (there are four types of garbage collectors available and we will see about them in the next tutorial) chosen either the marked instances will be removed from memory on the go or the eviction process will be done in a separate process.
Old Generation: Old or tenured generation is the second logical part of the heap memory. When the garbage collector does the minor GC cycle, instances that are still live in the S1 survivor space will be promoted to the old generation. Objects that are dereferenced in the S1 space is marked for eviction.
Major GC: Old generation is the last phase in the instance life cycle with respect to the Java garbage collection process. Major GC is the garbage collection process that scans the old generation part of the heap memory. If instances are dereferenced, then they are marked for eviction and if not they just continue to stay in the old generation.
Memory Fragmentation: Once the instances are deleted from the heap memory the location becomes empty and becomes available for future allocation of live instances. These empty spaces will be fragmented across the memory area. For quicker allocation of the instance it should be defragmented. Based on the choice of the garbage collector, the reclaimed memory area will either be compacted on the go or will be done in a separate pass of the GC.
Garbage Collector In java
Garbage Collector is part of JRE that makes sure that object that are not referenced will be freed from memory. Garbage collector can be viewed as a reference count manager. if an object is created and its reference is stored in a variable, its reference count is increased by one. during the course of execution if that variable is assigned with NULL. reference count for that object is decremented. so the current reference count for the object is 0. Now when Garbage collector is executed, It checks for the objects with reference count 0. and frees the resources allocated to it.
Advantage of Garbage Collection
- It makes java memory efficient because garbage collector removes the unreferenced objects from heap memory.
- It is automatically done by the garbage collector(a part of JVM) so we don't need to make extra efforts.
How can an object be unreferenced?
There are many ways:
- By nulling the reference
Student s=new Student();
s=null; - By assigning a reference to another
Student s1=new Student();
Student s2=new Student();
s1=s2;//now the first object referred by s1 is available for garbage collection - By annonymous object etc.
new Student();
The finalize() method is invoked each time before the object is garbage collected. This method can be used to perform cleanup processing. This method is defined in Object class as:
protected void finalize(){}
The Garbage collector of JVM collects only those objects that are created by new keyword. So if you have created any object without new, you can use finalize method to perform cleanup processing (destroying remaining objects).
gc() method
The gc() method is used to invoke the garbage collector to perform cleanup processing. The gc() is found in System and Runtime classes.
public static void gc(){}
Many people think garbage collection collects and discards dead objects.
In reality, Java garbage collection is doing the opposite! Live objects are tracked and everything else designated garbage.
When an object is no longer used, the garbage collector reclaims the underlying memory and reuses it for future object allocation. This means there is no explicit deletion and no memory is given back to the operating system. To determine which objects are no longer in use, the JVM intermittently runs what is very aptly called a mark-and-sweep algorithm.a
One of nicest features of Java is its rich, multifaceted nature. Sure, building traditional desktop and even mobile applications is all well and fine. But what if you want to leave your current background behind and start stepping on the web terrain? The good news is that the language ships with the fully-fledged Servlet API, which lets you build robust web applications without much hassle.
The question that must be spinning in your mind now is “How?”, am I right?
A Quick and Dirty Introduction to Java Servlets
Enter servlets, a specific type of Java program executed within the scope of a web container (also called servlet containers, Tomcat and Jetty are prime examples), which allows to handle client requests and server responses in a straightforward and performant fashion. This isn’t the place and time for boring you to tears with academic definitions on what a servlet is. Suffice it to say that servlets are instantiated and destroyed by their containers instead of the developer and act as a middle layer between clients (usually web browsers) and other applications running on the server (databases, for example).
Servlets are powerful creatures, which, among other nifty things, can grab data from the client, typically through GET and POST requests, handle cookies and session parameters, process the data via additional application layers, and send the output back to the client in both text and binary formats (HTML, XML, PDF, JPG, GIF, and so on), in many cases by using a Java Server Pages (JSP) file.
The best way to get started using servlets is with a concrete example. Thus, in the next few lines I’m going to build up a simple web application that will let customers sign up using a plain HTML form. Data submitted by customers will be collected by a servlet and validated at a very basic level through some static helpers.
Consuming the HTTP Client-Server Model
To have a clear idea on how the customer application will be structured, here’s how it will be laid out:
Nothing unexpected, right? But first things first.
The first step we need to take to build the application is to define the so-called deployment descriptor (DD). As the name suggests, it specifies how an application should be deployed in a specific environment. Not surprisingly when it comes to web applications, the deployment descriptor is a plain XML file called
web.xml and is part of the standard Java EE specification. In this particular case, it’ll look like this: <?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.1"
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
metadata-complete="false">
</web-app>
As shown above, the
web.xml file contains no directives at all and only defines the version of the Java Servlet Specification (3.1) that we’ll be using across the application. It can of course hold a lot more content, includingservlet mapping directives, intialization parameters, a list of welcome files and a few additional settings. But to keep the whole development process easy to follow, I’ll keep the file that simple.
Since the sample application will consume the Servlet API and also use Java Server Pages for displaying customer data, we need to grab all the required JARs. Maven will do the tough work for us, so here’s how the POM file will be defined:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.electricalweb.customerapplication</groupId>
<artifactId>customerapplication</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>Customer Application</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
<dependency>
<groupId>jstl</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
<version>2.2</version>
</dependency>
</dependencies>
<build>
<finalName>Customer Application</finalName>
</build>
</project>
In a nutshell, the
pom.xml file defines all the dependencies required for working with servlets: JSP, the Java Standard Tag Library (JSTL), and the Java Expression Language (JEL).
At this point, we’ve managed to create the customer app configuration files. However, in its current state the application literally does nothing. Yikes! Since the primary goal here is to let customers sign up using an HTML form, the next thing we need to do is to define the JSP files tasked with rendering the aforementioned form and with displaying customer data once the signup process has been successfully completed. That’s exactly the topic covered in the next section.
Creating the Sign-up and Welcome Views
The presentation layer will be made up of two JSP files – in an MVC context, these are called views. The first one will be responsible for rendering the signup form and for displaying eventual errors triggered after validating the inputted data. The second one will be a typical
welcome page, which will show the data submitted by the customer after successfully completing the signup process.
Here’s the first JSP file:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Customer Sign Up</title>
</head>
<body>
<h1>Customer Sign Up</h1>
<c:if test="${violations != null}">
<c:forEach items="${violations}" var="violation">
<p>${violation}.</p>
</c:forEach>
</c:if>
<form action="${pageContext.request.contextPath}/processcustomer" method="post">
<label for="firstname">First Name : </label>
<input type="text" name="firstname" id="firstname" value="${firstname}">
<label for="lastname">Last Name:</label>
<input type="text" name="lastname" id="lastname" value="${lastname}">
<label for="email">Email: </label>
<input type="text" name="email" id="email" value="${email}">
<input type="submit" name="signup" value="Sign Up">
</form>
</body>
</html>
The file contains plain HTML with a few tweaks. That’s the beauty of the JSP technology when coupled to JSTL and JEL. Notice how easy it is to check for validation violations and loop over them at the top of the file by using standard tags, like
<c:if> and <c:forEach>.
The signup form’s
action attribute points to the following URL: ${pageContext.request.contextPath}/processcustomer. In short, this means each time a customer tries to sign up, the data will be submitted to processcustomer regardless of the application’s context path. So no matter under which URL the signup form will eventually be available, the action’s URL is always relative to that. This is achieved thanks to the functionality of objects accessible from within a JSP file, such as request.
We will see below how the servlet is mapped to the
processcustomer URL and how it controls the inputted data. But before I define the servlet in question, here’s the JSP file that renders the welcome page: <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Customer Data</title>
</head>
<body>
<h1>Thanks for signing up with us!</h1>
<h2>You provided the following data:</h2>
<p><strong>First Name:</strong> ${firstname}</p>
<p><strong>Last Name:</strong> ${lastname}</p>
<p><strong>Email: </strong>${email}</p>
</body>
</html>
So far, so good. With the presentational layer already set, the next step is to create the servlet responsible for collecting customer data from POST requests and validate the data in a basic fashion.
Building a Customer Controller
Defining a servlet capable of grabbing the data entered in the previous signup form is a breeze, trust me. All that we need to do is subclass the native
HttpServlet class and implement its doGet() or doPost() methods (or both when required). In this particular case, the customer servlet will intercept data coming from POST requests.
Its definition is as follows:
@WebServlet(name = "CustomerController", urlPatterns = "/processcustomer")
public class CustomerController extends HttpServlet {
@Override
protected void doPost(
HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
RequestCustomer customer = RequestCustomer.fromRequestParameters(request);
customer.setAsRequestAttributes(request);
List<String> violations = customer.validate();
if (!violations.isEmpty()) {
request.setAttribute("violations", violations);
}
String url = determineUrl(violations);
request.getRequestDispatcher(url).forward(request, response);
}
private String determineUrl(List<String> violations) {
if (!violations.isEmpty()) {
return "/";
} else {
return "/WEB-INF/views/customerinfo.jsp";
}
}
private static class RequestCustomer {
private final String firstName;
private final String lastName;
private final String email;
private RequestCustomer(String firstName, String lastName, String email) {
this.firstName = firstName;
this.lastName = lastName;
this.email = email;
}
public static RequestCustomer fromRequestParameters(
HttpServletRequest request) {
return new RequestCustomer(
request.getParameter("firstname"),
request.getParameter("lastname"),
request.getParameter("email"));
}
public void setAsRequestAttributes(HttpServletRequest request) {
request.setAttribute("firstname", firstName);
request.setAttribute("lastname", lastName);
request.setAttribute("email", email);
}
public List<String> validate() {
List<String> violations = new ArrayList<>();
if (!StringValidator.validate(firstName)) {
violations.add("First Name is mandatory");
}
if (!StringValidator.validate(lastName)) {
violations.add("Last Name is mandatory");
}
if (!EmailValidator.validate(email)) {
violations.add("Email must be a well-formed address");
}
return violations;
}
}
}
The first point to stress here is the use of the
@WebServlet(name = "CustomerController", urlPatterns = "/processcustomer") annotation. It tells the servlet container to use the CustomerController class to handle HTTP requests to the /processcustomer URL. It’s possible to achieve the same behavior by including servlet mapping directives in the web.xml file, as shown here, but since I’m using the Servlet Specification 3.1, there’s not need to resort to mapping directives in the deployment descriptor. Just plain class-level annotations handle the mapping process for us.
In this case, I named the servlet
CustomerController as I’m clinging to a basic Model – View – Controller schema, hence the servlet behaves like a typical action controller. It’s feasible, however, to name it anything else, as long as the naming convention is consistent across the application. In general, it’s considered good practice to use the servlet class name as value for the @WebServlet annotation’s name attribute. Otherwise, some servlet containers will fail to do the mapping and throw an ugly HTTP status 404 error, telling you that the requested resource (the servlet itself) is not available.
That said, the
CustomerController class itself performs a few simple tasks. First of all, it collects the data entered in the signup form by using an implementation of the native HttpServletRequest interface, which holds the values corresponding to the firstname,lastname and email fields of the signup form. Secondly, it sets these values as request attributes, so they can be redisplayed either in the signup form view, or in the result view. Lastly, the data is validated by using a couple of static helpers, which check for empty strings and well-formed email addresses.
The validators themselves are simple classes, checking a couple of desired properties, for example whether the name is non-empty and the email address looks like, well, an email address.
The result of the validation process basically controls the application’s flow: If the data isn’t valid, the customer is forwarded through a request dispatcher object to the signup form view, and the errors are shown right there. Otherwise, the
welcome page is rendered, as the customer has successfully signed up.
At this point we’ve built a fully-functional web application that lets customers register by using an HTML form, a basic servlet, and a couple of JSP files. Maybe the biggest pitfall here is the use of static helpers for checking customer data instead of appealing to a standard approach, such as validating domain objects and even entire object graphs by using Java Bean Validation. The details on how to do this will be left as the topic of an upcoming article.
Running the app
If you’re anything like me, you should feel eager to run the application on your own development platform, that way can see for yourself if it works as sweet as I promised you at face value. To do so, just follow the steps below:
- As prerequisites you need Git (make sure to pick up the version that works with your operating system),Maven, and a servlet container (among others, Apache Tomcat, Jetty, or JBoss Wildfly). It is possible that your IDE ships with one or more of these systems, in which case you can use the embedded versions.
- Use Git to clone the application repository to your local machine and import it into your IDE, preferably as a Maven project.
- Deploy the whole project to the servlet container and run it. Deploying the project means building a WAR file(Web archive) or an exploded WAR (aka exploded deployment) and placing it in the servlet container’s default deployment folder. In many cases your IDE will deploy the project automatically for you, whenever you hit theRun button, so don’t mess up your life trying perform this task manually unless you have to. Check your IDE’s documentation for details (here it is for IntelliJ IDEA. Once the project has been properly deployed, and if everything goes as expected, the default browser will pop up and you’ll see the customer signup form.
- Try submitting the form with no values at all, or even with some missing values (there’s plenty of room to experiment here). You’ll see the errors nicely displayed on top of the form according to the offending inputs. Finally, if you’re nice and provide the mandatory data, you’ll be confronted with the welcome page.
Feel free to pat yourself in the back. Congratulations! You’ve developed a fully-functional Java web application.
Final Thoughts
At this point you have acquired all the skills required to kick off building your own Java web application and, best of all, without having to resort to the complexities of any framework at all. All you need is to consume the Servlet API, use some kind of rendering technology, such as JSP and plain Java. Isn’t that great?
It’s worth noting that the implementation of the
CustomerController class highlights the virtues and flaws exposed by servlets: On one hand it shows in a nutshell how easy it is to handle request parameters and send responses back to the client in different formats. But this functionality comes at a price: Both implementations of theHttpServletRequest and HttpServletResponse interfaces are plain service locators. This is not inherently bad, as the locators are just data holders. Unfortunately, whenever you drop a servlet into your application scope, you’ll have those implementations coupled to it.
