Which is more secure in an HTTP server, GET or POST?
POST is more secure than GET for a couple of reasons. GET parameters are passed via URL. This means that parameters are stored in server logs, and browser history. When using GET, it makes it very easy to alter the data being submitted the the server as well, as it is right there in the address bar to play with.
The problem when comparing security between the two is that POST may deter the casual user, but will do nothing to stop someone with malicious intent. It is very easy to fake POST requests, and shouldn’t be trusted outright.
The biggest security issue with GET is not malicious intent of the end-user, but by a third party sending a link to the end-user. I cannot email you a link that will force a POST request, but I most certainly can send you a link with a malicious GET request.
GET vs POST comparison table
|BACK button/Reload||Harmless||Data will be re-submitted (the browser should alert the user that the data are about to be re-submitted)|
|Bookmarked||Can be bookmarked||Cannot be bookmarked|
|Cached||Can be cached||Not cached|
|Encoding type||application/x-www-form-urlencoded||application/x-www-form-urlencoded or multipart/form-data. Use multipart encoding for binary data|
|History||Parameters remain in browser history||Parameters are not saved in browser history|
|Restrictions on data length||Yes, when sending data, the GET method adds the data to the URL; and the length of a URL is limited (maximum URL length is 2048 characters)||No restrictions|
|Restrictions on data type||Only ASCII characters allowed||No restrictions. Binary data is also allowed|
|Security||GET is less secure compared to POST because data sent is part of the URL
Never use GET when sending passwords or other sensitive information!
|POST is a little safer than GET because the parameters are not stored in browser history or in web server logs|
|Visibility||Data is visible to everyone in the URL||Data is not displayed in the URL|
What is a web application firewall (WAF)?
A web application firewall filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
The WAF is deployed as a hardware appliance, inline web server, or server plugin that runs directly on web servers. It intercepts all HTTP requests and analyzes each of them before they reach the web server for processing. It analyzes GET and POST requests while applying defined rules to identify and filter out illegitimate traffic.
Depending on the selected WAF options, the WAF can block the traffic, challenge the visitor by asking them to input a CAPTCHA, or instruct the server to simulate an attack. The blocking and challenging options prevent any illegitimate traffic from reaching the web server.
What does the Web Application Firewall (WAF) do?
The Web Application Firewall (WAF) works by examining HTTP requests to your website. It inspects both GET and POST requests and applies rules to help filter out illegitimate traffic from legitimate website visitors. For example, it looks for common keywords used in comment spam and stops the action before it is posted to the web property.
What is a Stack Trace?
A stack trace is a report that provides information about program subroutines. It is commonly used for certain kinds of debugging, where a stack trace can help software engineers figure out where a problem lies or how various subroutines work together during execution.
A stack trace is a report of the active stack frames at a certain point in time during the execution of a program. It is commonly used during interactive and post-mortem debugging. It can also be displayed to the user of a program as part of an error message, which a user can report to a programmer. A stack trace allows to track the sequence of nested functions called up to the point where the stack trace is generated. In a post-mortem scenario this is up to function where the failure occurred. Sibling function calls are not visible in a stack trace. As an example, the following Python program contains an error. Running the program under the standard Python interpreter produces the following error message. The stack trace shows where the error occurs, namely in the c function.
What is the Document Object Model?
The Document Object Model (DOM) is a cross-platform and language-independent application programming interface that treats an HTML, XHTML, or XML document as a tree structure wherein each node is an object representing a part of the document. The objects can be manipulated programmatically and any visible changes occurring as a result may then be reflected in the display of the document.
The DOM defines a standard for accessing documents:
“Document Object Model (DOM) is a platform and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure, and style of a document.
The W3C DOM standard is separated into 3 different parts:
- Core DOM – standard model for all document types
- XML DOM – standard model for XML documents
- HTML DOM – standard model for HTML documents
What is Same Origin Policy (SOP)?
Same-origin Policy (SOP), which defines borders for each resource loaded by a browser. According to this rule, all resources loaded by a browser will be defined by a string which is known as the origin, consisting of the protocol, URL, and port being used to reach the resource.
Same origin policy (SOP) is a security mechanism in a client browser that permits webpage scripts to access their associated website’s data and methods but restricts its access to scripts and data stored by other websites.
the rules that Same-origin Policy defines:
- Each page takes its origin from its URL (normally schema, domain, and port).
- Scripts run in the context of the origin which they are loaded. It does not matter where you load it from, only where it is finally executed.
- Many resources, like media and images, are passive resources. They do not have access to objects and resources in the context they were loaded.
Same-origin Policy in Detail
Imagine we have a web page hosted at http://www.myexample.com/pat/test.html. Within this document is an iframe that loads a different web page. Our source host is defined as www.myexample.com. The following table depicts the full URLs we want to reach, and whether or not they are reachable due to Same-origin Policy:
|http://www.myexample.com/pat/page.htm||Accessible||Protocol, host and port match|
|http://www.myexample.com/pat2/other.htm||Accessible||Protocol, host and port match|
|http://www.myexample.com:81/pat/test.htm||Not Accessible||Same protocol and host, but port is different (81)|
|https://www.myexample.com/pat/test.htm||Not Accessible||Same host, but schema/protocol (https) different|
|http://demo.myexample.com/pat/test.htm||Not Accessible||Schema and port are same, but host is different (demo.myexample.com)|
|http://myexample.com/pat/test.htm||Not Accessible||Host is different (example.com)|
|http://www2.myexample.com/pat/test.htm||Not Accessible||Host is different (www2.myexample.com)|
What is SSL Stripping?
In simple words, SSL Strip is a type of Man-in-the-middle attack technique by which a website secured with HTTPS is downgraded to HTTP. In SSL Strip, all the traffic coming from the victim’s machine is routed towards a proxy which is created by the attacker.
SSL Strip attacks can be implemented in a number of ways. Three of the most common methods are listed below:
- Manually set the proxy of the browser to route all traffic
- ARP Poisoning
- Create a Hotspot and allow the victims connect to it
The origin of SSL Strip was based on simple observation that most users are not coming to SSL websites by directly typing in the URL or a bookmarked Https:// url. Mostly, visitors connects to a non-SSL site and it gets redirected (eg.: HTTP 302 redirect), or they will connect to a non-SSL site which have a link to SSL site and they click that link.
How to protect my website against SSL Strip attacks?
Due to its nature, the SSL Strip can work only on websites that don’t encrypt pages beyond the login page. Websites that use both HTTP and HTTPS in their setup are prone to various security threats including the SSL Strip. To stay on the safe side, always use an SSL Certificate throughout the whole website. In other words, make sure to host all your content such as pictures, files and videos on HTTPS. Another layer of security capable of stopping the Strip is HSTS (Strict Transport Security). This mechanism instructs the browser to always connect only via HTTPS and not http.
- Enable SSL site wide (i.e., use HTTPS only).
- Enable HSTS (HTTP Strict Transport Security).
- Enable Cert Pinning.
- Enable secure cookies, i.e., ensure that all cookies are served with the secure attribute, so that your user’s browsers will only send those cookies back over SSL-protected connections and never disclose them over any non-SSL (HTTP) link.
- Disable HTTP (non-SSL) access, or redirect users to the SSL version of the web site.
What is a Man-in-the-Middle Attack and how can you prevent it?
In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. One example of man-in-the-middle attacks is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones.
Data is sent from point A (computer) to point B (server/website), and an attacker can get in-between these transmissions. They then set up tools programmed to “listen in” on transmissions, intercept data that is specifically targeted as valuable, and capture the data. Sometimes this data can be modified in the process of transmission to try to trick the end user to divulge sensitive information, such as log in credentials. Once the user has fallen for the bait, the data is collected from the target, and the original data is then forwarded to the intended destination unaltered.
What is ICMP (Internet Control Message Protocol)?
ICMP (Internet Control Message Protocol) is an error-reporting protocol network devices like routers use to generate error messages to the source IP address when network problems prevent delivery of IP packets. ICMP creates and sends messages to the source IP address indicating that a gateway to the Internet that a router, service or host cannot be reached for packet delivery. Any IP network device has the capability to send, receive or process ICMP messages.
ICMP is not a transport protocol that sends data between systems.
While ICMP is not used regularly in end-user applications, it is used by network administrators to troubleshoot Internet connections in diagnostic utilities including ping and traceroute.
ICMP messages are transmitted as datagrams and consist of an IP header that encapsulates the ICMP data. ICMP packets are IP packets with ICMP in the IP data portion. ICMP messages also contain the entire IP header from the original message, so the end system knows which packet failed. ICMP for IPv4 is defined in RFC 792.
The ICMP packet is encapsulated in an IPv4 packet. The packet consists of header (type, code, checksum,rest of header) and data (0 – Echo Reply) sections.
What is the list of HTTP header fields?
What is the difference between Sessions and Cookies?
A cookie is a small piece of text stored on a user’s computer by their browser. Common uses for cookies are authentication, storing of site preferences, shopping cart items, and server session identification. Each time the users’ web browser interacts with a web server it will pass the cookie information to the web server. Only the cookies stored by the browser that relate to the domain in the requested URL will be sent to the server. This means that cookies that relate to www.example.com will not be sent to www.exampledomain.com.In essence, a cookie is a great way of linking one page to the next for a user’s interaction with a web site or web application.
A session can be defined as a server-side storage of information that is desired to persist throughout the user’s interaction with the web site or web application.
Instead of storing large and constantly changing information via cookies in the user’s browser, only a unique identifier is stored on the client side (called a “session id”). This session id is passed to the web server every time the browser makes an HTTP request (ie a page link or AJAX request). The web application pairs this session id with it’s internal database and retrieves the stored variables for use by the requested page.
What is the difference between SSL and TLS?
SSL stands for Secure Sockets Layer and, in short, it’s the standard technology for keeping an internet connection secure and safeguarding any sensitive data that is being sent between two systems, preventing criminals from reading and modifying any information transferred, including potential personal details.
TLS (Transport Layer Security) is just an updated, more secure, version of SSL. We still refer to our security certificates as SSL because it is a more commonly used term, but when you are buying SSL from Symantec you are actually buying the most up to date TLS certificates with the option of ECC, RSA or DSA encryption.
HTTPS (Hyper Text Transfer Protocol Secure) appears in the URL when a website is secured by an SSL certificate. The details of the certificate, including the issuing authority and the corporate name of the website owner, can be viewed by clicking on the lock symbol on the browser bar.