Technide

Google Hacking Guide Resource from           By Ken Foster – KMBL Security For educational purposes only.    Not for use in matters or on sites you are not implicitly and legally approved to research By Ken Foster – KMBL Security                    What is Google hacking? The purpose of Google Hacking is to leverage the vast amounts of data that are stored and indexed in search engines to produce unique results that quickly identify sensitive information, vulnerable systems, and network tactics and methods used by their hosts.    These methods are beneficial to security professionals, ethical hackers, and unfortunately black hats.    Who is Google Hacking? Google hacking has become very popular among security testers, ethical hackers, and unfortunately script kiddies and hackers who all too well understand its value. Is it Illegal? This is debatable and dependent upon the country or state you live in and the location of the target.   As a

Google Hacking Queries easiest way to filter any specified path in google Filetype can be search any file types according passwords  videos and many more things you can search please when you searching type the word like this filetype:stephanhawking or type with " " qutations like these filetype:"StephanHawking" Index: index meaning unprotected  types ex: Filetype:password Then displaying these kind of page filetype : filetype:bak createobject sa filetype:bak inurl:"htaccess|passwd|shadow|htusers" filetype:cfg mrtg "target filetype:cfm "cfapplication name" password filetype:conf oekakibbs filetype:conf slapd.conf filetype:config config intext:appSettings "User ID" filetype:dat "password.dat" filetype:dat inurl:Sites.dat filetype:dat wand.dat filetype:inc dbconn filetype:inc intext:mysql_connect filetype:inc mysql_connect OR mysql_pconnect filetype:inf sysprep filetype:ini inurl:&quo

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page. For more details on the different types of XSS flaws, see:  Type

SQL injection   is a  code injection  technique, used to  attack  data-driven applications, in which nefarious  SQL  statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker). [1]  SQL injection must exploit a  security vulnerability in an application's software, for example, when user input is either incorrectly filtered for  string literal   escape characters  embedded in SQL statements or user input is not  strongly typed  and unexpectedly executed. SQL injection is mostly known as an attack  vector  for websites but can be used to attack any type of SQL database. SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server. SQL injection is a code injection technique th

As I mentioned in my previous blog post about CSRF & Synchronizer Tokens , we can mitigate Cross Site Request Forgery AKA CSRF also by the technique called " Double Submit Cookies ". In here, the basic thing happens is, the server generates the CSRF token and set it as a cookie in the browser (need to specify the domain address), as well as the server will create the session cookie with the value of the session id. This whole thing happens when the event of a user login. When a state changing request occur, the web page will get the CSRF cookie and add its value to a hidden field in the HTML DOM, same as the Synchronizer token pattern. When the event of the authorization, server will validates the cookie value of the CSRF cookie with the received token value from the DOM. This way we can prevent CSRF attacks from occurring using the " Double Submit Cookies pattern " Attackers cannot perform a CSRF attack because, they need the token to do it obviously, and