Is htmlspcialchars($user_data)
in PHP or h(user_data)
in Ruby on Rails good enough for defending all cases of XSS (Cross-site scripting) attacks? What about encoding used or any other possible considerations?
相关问题
- “Zero out” sensitive String data in Swift
- Request.PathInfo issues and XSS attacks
- High cost encryption but less cost decryption
- How to restrict VOB read access in ClearCase (Wind
- Is it appropriate to secure/hide Swagger/OpenAPI S
相关文章
- Warning : HTML 1300 Navigation occured?
- Security concerns about CORS
- How do I prevent SQL injection with ColdFusion
- LINQ to Entities and SQL Injection
- How to use Google application-specific password in
- Will re-populating a password field in a form be a
- AWS - Configuring access to EC2 instance from Bean
- Shiro complaining “There is no session with id xxx
Both
htmlspecialchars
andh
escape all characters that may have special meaning in HTML, there is no way that literal HTML may be injected into the target page.However, there are ways to execute (dangerous) Javascript that do not require HTML injection. For example, if you have an application that converts
[img http://example.com/img.jpg]
to<img src="http://example.com/img.jpg/>
, imagine what may happen if a user enters[img javascript:alert(document.cookies);]
. Escaping HTML characters will not save you here, you have to sanitise the given URLs. This is a fairly comprehensive list of possible XSS vulnerability examples.If you always use
htmlspecialchars
/h
and you always completely sanitise user input that is used as attribute values in any HTML elements, then you have a proper XSS defence.In general there are three different types of XSS: the DOM-based, the Non-Persistent and the Persistent.
Now server-side languages can only prevent the latter two (Non-Persistent and Persistent) as the first only takes place on the client-side.
You can also try to use strip_tags if you don't allow HTML tags in postings. Also check out the html purifier