sql injection , csrf , xss (cross site scripting)

sql injection , csrf , xss (cross site scripting) ::

.....................................................................................................

Link for CSRF :: https://medium.com/rubyinside/a-deep-dive-into-csrf-protection-in-rails-19fa0a42c0ef#:~:text=Briefly%2C%20Cross%2DSite%20Request%20Forgery,their%20authenticity%20with%20each%20submission.

CSRF :: CROSS SITE REQUEST FORGERY ::

CSRF - cross site request forgery is an attack that allows a malicious user to allow legitimate requests to your server masquerading as an authenticated user .Rails protects against this kind of attack by using by generating unique tokens and validating their authenticity with each submission.

There are two components of CSRF ::

First :: A unique token is embedded in your site's html .

Second :: The same token is also stored in your session cookie .

When a user makes a POST request the csrf token from the html gets sent with that request . rails compares the token from the page with the token from the session cookie to ensure they match .

add these two lines in the application_controller.rb ::

.........................................................................................................................

protect_from_forgery with: :exception

<%= csrf_meta_tags %>

.........................................................................................................................

This csrf is make in particular csrf file inside your project ::

actionview/lib/action_view/helpers/csrf_helper.rb

def csrf_meta_tags

	if defined?(protect_against_forgery?) && protect_against_forgery?
	[
	tag("meta", name: "csrf-param", content: request_forgery_protection_token),
	tag("meta", name: "csrf-token", content: form_authenticity_token)
	].join("\n").html_safe
	end
	end before_action :verify_authenticity_token, options is used in application_controller.rb

How to prevent from CSRF Attacks ::

1. use of security token ::

2. protect_from_forgery ::

You must include a security token using: protect_from_forgery in your requests and MUST verify it on the server. This will automatically include a security token in all forms and Ajax requests generated by Rails. If the security token doesn't match what was expected, the session will be reset.

Link ::

https://www.bigbinary.com/books/learn-rubyonrails-book/preventing-csrf-attacks

very good above link

Handling unverified requests

If a request fails the forgery check then we have three ways to handle it:

Raise an exception
Reset the session
null session for the duration of the request

Raise an exception

1class ApplicationController < ActionController::Base
2  protect_from_forgery with: :exception
3end

In this case if a request is submitted and forgery check fails then ActionController::InvalidAuthenticityToken exception is raised. We can rescue this exception and we can take whatever action we want to take.

Reset the session

1class ApplicationController < ActionController::Base
2  protect_from_forgery with: :reset_session
3end

In this case if a request is submitted and forgery check fails then session is completely reset.

Let's say that in our application user is logged in, and it has many pages and each page has a form. Let's assume that in one of the forms the developer forgot to send CSRF value. When a logged-in user submits that form then Rails will detect that no CSRF token is sent. In this case Rails will reset the session.

Resetting the session means that user is no longer logged in. So the end result is that after submitting the form which does not send CSRF token user will be logged out.

Note that in this case Rails is not preventing the request from going through. It's just setting the session as empty. Now if the intended controller and the action expects a person to be logged in then the request will fail with a different error.

Empty session during the request

1class ApplicationController < ActionController::Base
2  protect_from_forgery with: :null_session
3end

In this case if a request is submitted and forgery check fails then Rails provides an empty session. But the important thing here is that the empty session is only for the duration of the call. After the request is processed then the old session is restored.

There is nothing to commit in this chapter since all we had done was learning the basics of CSRF attack prevention.

..................................................................................................... ..................................................................................................... ..................................................................................................... ..................................................................................................... ..................................................................................................... ..................................................................................................... ..................................................................................................... .......................................................................................................... ........

XSS :: CROSS SITE SCRIPTING ::

Link :: https://www.invicti.com/blog/web-security/preventing-xss-ruby-on-rails-web-applications/

Very very good link for xss .

Link :: https://molily.de/xss/

............................................................................................................................

Cross site scripting is a very common injection type of web application vulnerability. It allow attackers to inject any type of client side script which is then executed by the victims browsers in their browsing context. Typically cross-site scripting attacks are used to bypass access controls and to steal web sessions.

Ruby on Rails has a built-in XSS protection mechanism which automatically HTML escapes all the data being transferred from Rails to HTML. While this is a big plus for Rails framework security, it is not enough to solve all XSS problems, which is why every day new cross-site scripting vulnerabilities are still being discovered on Ruby on Rails web applications.

Q -- how to prevent from xss attacks ::

To prevent XSS attacks, Rails automatically escapes all data sent from Rails to HTML output.

XSS Preventions ::

https://semgrep.dev/docs/cheat-sheets/rails-xss/

1. unescaped variable enters template engine in ruby apps.

A. using html_safe

B. using content_tag()

C. using raw()

D. disabling of active support # escape_html_entities_in_json

2. bypassing the template engine

A. manually creating an erb template

B. rendering an erb template with render inline

C. using render text

3. Templates: Variable explicitly unescaped

A. using html_safe

B. using content_tag()

C. using raw()

D. Using <%== ... %>, which is an alias for html_safe()

4. Templates - Variable in dangerous location

A. Unquoted variable in HTML attribute

B. Variable in href attribute

C. Using link_to with unrestricted URL scheme

D. Variable in <script> block

:: SQL Injection ::

Very imp defintion ::

If you were able to somehow force the application to change user_id in the above query, you'd be able to get the orders of other users. And that's what we call a SQL injection attack: an ability to modify the SQL query that an application is executing against the database.

Imp links :::

https://www.cloudsecuretech.com/how-to-fix-the-sql-injection-vulnerability-in-ruby-on-rails/

how to prevent sql injection attacks in rails ::

1. single parameter query

2. compounded queries

3. like queries

Search This Blog

Dwijendra Parashar