Skip to main content

Posts

Showing posts from 2013

SQL Injection Test 1

Search Google about Dork List 2013 SQL Injection Here are some from the list is :       http://tutsql.blogspot.com/2013/06/dork-list.html       http://securitypedia.blogspot.com/p/dork-list-2013_7588.html     -- choose one way of them to google it like : inurl:newsdetail.php?id=

SQL Injection & Data Store Manipulation

Web sites store ever-increasing amounts of information about their users, users’ habits, connections, photos, inances, and more. These massive datastores present appealing targets for attackers who wish to cause damage or make money by maliciously accessing the information. While credit cards often spring to to mind at the mention of SQL injection any information has value to the right buyer. In an age of organized hacking, attackers will gravitate to the information with the greatest value via the path of least resistance. Here we examine an attack directed solely against the web site and its database: SQL injection. A single SQL injection attack can extract the records for every user of the web site, regardless of whether that user is logged in, currently using the site, or has a secure browser.

HTML injection and cross-site scripting (XSS)

HTML injection and cross-site scripting (XSS) is an ideal vulnerable to exploitfor attackers across the spectrum of sophistication and programming knowledge. Exploits are easy to write, requiring no more tools than a text editor—or sometimes just the browser’s navigation bar—and a cursory knowledge of JavaScript, unlike buffer overlow exploits that call for more esoteric assembly, compilers, and debugging. XSS also offers the path of least resistance for a payload that can affect Windows, OSX, Linux, Internet Explorer, Safari, and Opera alike. The web browser is a universal platform for displaying HTML and interacting with complex web sites. When that HTML is subtly manipulated by a few malicious characters, the browser becomes a universal platform for exposure. With so much personal data stored in web applications and accessible through URLs, there’s no need for attackers to make the extra effort to obtain “root” or “administrator” access on a victim’s system. The reason for targ...

CSSLP - Certified Secure Software Lifecycle Professional (overview)

The following is example of secure software controls that should be considered through the life cycle of a software development project. Depending on the type of organizations, some or all of these controls should be factored. Military organizations generally have stringent controls that need to be built in than civilian organizations. Security in the Systems Development Life Cycle Requirements Gathering Business Partner Engagement Identify Policies & Standards Identify Regulatory & Legal Requirements Identify Privacy Requirements Identify Compliance Requirements Develop C,I, A* Goals & Objectives Develop Procurement Requirements Perform Risk Assessment Design Use and Abuse Case Modeling Secure Design Review Secure Architecture Review Threat & Risk Modeling Generate Security Requirements Generate Security Test Cases Develop...

Web Security in few lines

   Insufficient Transport Layer Protection  Authenticating over non-­‐SSL. Obviously bad Sending session IDs over non-­‐SSL Session hijacking Firesheep Not sending everything over SSL JavaScript injection Insecure Cryptographic Storage Obviously bad  Storing passwords in plaintext.  Still bad  Using unsalted hashes. Using raw hash function (MD5,SHA1,etc). Better but not great  Using a keyed hash function (HMAC-SHA1). Best Using a slow function (PBKDF2,bcrypt,scrypt).  Cross-Site Request Forger y  Confused deputy problem.  Classic example  Filelocker doesn’t have any CSRF protection. Joe is a Filelocker admin. I get Joe to visit a specially crafted form. Joe’s browser submits form along  with  his cookies. I not have admin  <form method="POST" action="[path to filelocker]/admin_interface/grant_user_permission?format=json"> <input type="hidden" name="us...

About Security

Most Important People Security (Increase Expenses) Developers (Increase Profits) Executives (Increase Profits) Sales (Increase Profits) Business Development (Increase Profits)

Smurf Attack

 Definition - What does Smurf Attack mean? A smurf attack is a type of denial of service attack in which a system is flooded with spoofed ping messages. This creates high computer network traffic on the victim’s network, which often renders it unresponsive. Smurfing takes certain well-known facts about Internet Protocol and Internet Control Message Protocol (ICMP) into account. ICMP is used by network administrators to exchange information about network state, and can also be used to ping other nodes to determine their operational status. The smurf program sends a spoofed network packet that contains an ICMP ping. The resulting echo responses to the ping message are directed toward the victim’s IP address. Large number of pings and the resulting echoes can make the network unusable for real traffic. Techopedia explains Smurf Attack The following steps lead to a smurf attack: Huge numbers of ICMP requests a...

How applications get build in the real world!!!!!!!

Some Important things

  Filter Input & Escape Output, always.  Use prepared statements, filter your query params.  Disable magic_quotes, register_globals, allow_url_fopen.  Give minimum permissions to daemons, processes, people.  Regenerate your session id’s and use tokens.  Use common sense.

jQuery safety

Some jquery methods are unsafe, particularly .append() and the jquery selector $('') which can also create nodes $('<img>') will generate a img node. Only a few jquery methods should be passed unescaped input Safe methods .text() .attr() .prop() .val() Unsafe methods .html() $() .append*() .wrap*() .prepend*() .before() .after() .insert*()

Security is a Mindset

Three Principles: Defense in Depth - Redundant safegaurds are valuable. Least Privilege - grant as little freedom as possible.  Least complicated - Complexity breeds mistakes.  (From Shiflett's Evolution of Web Security)   Trust Nothing, Assume Nothing Server Side Security  Install Suhosin patch.  Be smart about your passwords.  Disable register globals, magic quotes,etc.  Never run PHP/Apache/Nginx/etc as administrator.  Keep up with Patches.

Social Engineering - 1

Phishing - Getting information by simply asking for it. Baiting - Leaving infected media (USB Stick, CD’s, wireless networks, etc) that compromises a system. Tailgating - Entering a secured area by following someone.  Social Engineering - Tips  Don’t give out privileged information, ever.  Know who you’re talking to, ask to call them back, etc.  Common Sense helps a lot.  Never take anything for granted.  Don’t pick up disks/usb sticks/etc & insert them into your computer (PC, Mac,or even Linux)

Your plan to protect yourself from SQL Injection

SQL injection is  serious business , but you shouldn't be overwhelmed by the thought of defending against it. Follow these simple steps to keep attackers' eyes and fingers out of your databases. Ensure that only generic, nondescriptive error message or HTTP 500 pages are displayed to users. Never give away database metadata like table names or application source code snippets in error messages.  Validate simple input types like credit card numbers or postal codes with regular expression. If the input doesn't match the expected value, return an error to the user ( a generic, nondescriptive error!) and don't execute the database query. Always check to make sure that the input matches a good , valid pattern ( for example , whitelist pattern matching) rather than whether it matches a bad,invalid pattern(for example,blacklist matching). Whitelist validation defenses are usually much more resilient to newly discovered attack techniques.  If the input is a date or numer...

Web Application Security Scanner : Sandcat

Sandcat is multi-process remote web application security scanner. It maps the entire web site structure ( all links , forms , XHR requests and other entry points) and tries to find custom,unique vulnerabilities by simulating a wide range of attacks/sending thousands of requests (mostly GET and POST).  It also tests for SQL Inection, XSS, File inclusion and many other web application vulnerability classes.  Sandcat's code scanning functionality automates the process of reviewing the web application's code .  Source : CEH Lectures ...

Protecting against XSS

The problem as I see it..... Where to start? Let me start by telling you that most of the books you read are wrong. The code samples you copy of the internet to do a specific task are wrong (the wrong way to handle a GET request), the function you copied from that work colleague who in turn copied from a forum is wrong (the wrong way to handle redirects). Start to question everything. Maybe this post is wrong this is the kind of mindset you require in order to protect your sites from XSS. You as a developer need to start thinking more about your code. If a article you are reading contains stuff like echo $_GET or Response.Write without filtering then it’s time to close that article. Are frameworks the answer? I think in my honest opinion no. Yes a framework might prevent XSS in the short term but in the long term the framework code will be proven to contain mistakes as it evolves and thus when it is exploited it will be more severe than if you wrote the code yourself. Why more ...

SSL in Authorization

Some web applications use SSL to protect the application's authentication page,because this prevents the user's password from traveling in the clear and thus protects the password from eavesdropping attacks, but then they don't use SSL to encrypt the rest of the application's traffic. This largely renders the password orrelevant, however,because the attacker can still snoop on the unencrypted traffic in order to steal the session ID and impersonate the user that way. If you're going to use SSL at all,you really want to use it for your whole application. Resource : Web Application Security, A beginners Guide , By : Bryan Sullivan & Vincent Liu

Firesheep & unencrypted cookies

Firesheep is a tool that highlights the weakness of unencrypted cookies. The use of unencrypted cookies is such a serious security vulnerability that they have led some security activists to exploit them on purpose, merely to demonstrate how insecure they really are.  Firesheep is a browser extension for the Firefox browser, which literally makes it point-and-click easy for someone to steal session IDs from certain popular social networking web sites and impersonate other users. Firesheep works by packet sniffing. It watches for the unencrypted session ID values stored in cookies to pass by on whatever section of Internet traffic it can see,captures those values, and presents them to the attacker within the attacker's web browser along with the victim's name. When the attacker double-clicks on a victim's name, Firesheep substitutes the stolen session ID value in place of its own,which allow the attacker to impersonate the victim. There is no way of knowing how many vic...

Cross-Site Scripting

Cross-site scripting is without a doubt the worst-named web application vulnerability in the world  . So many people have trouble understanding what XSS is just because of its awful name. One time , I was at a developer conference, and between sessions I had struck up a conversation with a programmer. We started talking about web security in his application, and I asked him what he was doing about cross-site scripting. he answered, "Oh , we don't have to worry about that. we don't use cross-site scripting." I explained to him that XSS isn't something that you use; it's something that attackers use against you!  By the end of our talk, he was straightened out, but I can't help wondering how many more programmers like him are out there who are ignoring XSS because they think it's a feature that they're not using. If it had been up to me, I probably would have called it "JavaScript Injection," which I think is a much more accurate de...

Sample of attacks in the first half of 2011

 Small sample of attacks in the first half of 2011 alone includes: The SQL injection attacks on the Sony Music web sites in MAY 2011 by the LulzSec organization.While unconfirmed by Sony, it's also believed that SQL injection vulnerabilities were responsible for the attacks against the Sony PlayStation Network and Qriocity that leaked the private data of 77 million users and led Sony to shut down the services for over a month. The overall cost of this breach to Sony has been estimated to exceed 171 million dollars (US). A cross-site scripting vulnerability in the Andoid Market discovered in March 2011 that allowed attackers to remotely install apps onto users' Andiod devices without their knowledge or consent.  The Attack of information security firm HBGary Federal in Feb. 2011 by the hacker group Anonymous. Another simple SQL injection vulnerability in the www.hbgaryfederal.com website,combined with a poorly implemented use of cryptographic hash function, enabled Anonym...

Your Plan to Secure your code

Never trust the user!  Validate all input coming from a user. This includes any part of an HTTP request that you're processing: the header names and values, the cookie names and values, the querysting parameters, web form values, and any other data included in the message body.  Always use whilelist input validation to test input; that is, test whether an input does match an expected good format and reject it if it doesn't. Avoid blacklist input validation; that is, testing whether an input matches an expected bad format and rejecting it if it does.  Never perform validation just on client side - an attacker can easily bypass these controls. Always validate on the server side.  Use regular expressions for more complicated validation logic like testing e-mail addresses. Unless you're a regex expert, also consider using regex from one of the public databases such as regexlib.com or a commercial regex ...