Sql injections (Basic bypass authentication)

Sql injections (Basic bypass authentication)

• 1.
  BY :- RAVINDRASINGH RATHORE BRANCH :- COMPUTER SCIENCE BATCH :- B3 SQL INJECTIONS
• 2.
  SQL Injections
• 3.
  The ability toinject SQL commands into the database engine through an existing application What is SQL Injection?
• 4.
  SQL Injection  Generally,the purpose of SQL injection is to convince the application to run SQL code that was not intended.  SQL injection occurs when an application processes user-provided data to create a SQL statement without first validating the input.
• 5.
  SQL Injection  Theuser input is then submitted to a web application database server for execution.  When successfully exploited, SQL injection can give an attacker access to database content or allow the hacker to remotely execute system commands.  In the worst-case scenario, the hacker can take control of the server that is hosting the database.
• 6.
  6 SQL Injection  Thisexploit can give a hacker access to a remote shell into the server file system.  The impact of a SQL injection attacks depends on – where the vulnerability is in the code, – how easy it is to exploit the vulnerability, – what level of access the application has to the database.  Theoretically, SQL injection can occur in any type of application, but it is most commonly associated with web applications.  The web applications are easy targets because by their very nature they are open to being accessed from the Internet.
• 7.
  It is probablythe most common Website vulnerability today! It is a flaw in "web application" development, it is not a DB or web server problem Most programmers are still not aware of this problem A lot of the tutorials & demo “templates” are vulnerable Even worse, a lot of solutions posted on the Internet are not good enough In our pen tests over 60% of our clients turn out to be vulnerable to SQL Injection HOW COMMON IS IT?
• 8.
  8 How does SQLInjection work? Common vulnerable login query SELECT * FROM users WHERE login = ‘silent' AND password = ‘hexor' (If it returns something then login!) ASP/MS SQL Server login syntax var sql = "SELECT * FROM users WHERE login = '" + formusr + “’ AND password = '" + formpwd + "'";
• 9.
  9 Injecting through Strings formusr= ' or 1=1 – – formpwd = anything Final query would look like this: SELECT * FROM users WHERE username = ' ' or 1=1 – – AND password = 'anything'
• 10.
  10 SQL Injection Defense Itis quite simple: input validation The real challenge is making best practices consistent through all your code Enforce "strong design" in new applications You should audit your existing websites and source code Even if you have an air tight design, harden your servers
• 11.
  11  Define datatypes for each field  Implement stringent "allow only good" filters  If the input is supposed to be numeric, use a numeric variable in your script to store it  Reject bad input rather than attempting to escape or modify it Input Validation
• 12.
  12 1. Run DBas a low-privilege user account. 2. Remove unused stored procedures and functionality or restrict access to administrators. 3. Change permissions and remove "public" access to system objects. 4. Audit password strength for all user accounts. 5. Firewall the server so that only trusted clients can connect to it (typically only: administrative network, web server and backup server). Harden the Server
• 13.
  13  You maywant to react to SQL injection attempts by:  Logging the attempts  Sending email alerts  Blocking the offending IP  Sending back intimidating error messages:  "WARNING: Improper use of this application has been detected. A possible attack was identified. Legal actions will be taken."  Check with your lawyers for proper wording  This should be coded into your validation scripts Detection and Dissuasion
• 14.
  14  SQL Injectionis a fascinating and dangerous vulnerability  All programming languages and all SQL databases are potentially vulnerable  Protecting against it requires  strong design  correct input validation  hardening Conclusion
• 15.
  THANK YOU…