Tag Info

Hot answers tagged

11

Simple. You read the anti-CSRF token from the newly requested login page and each time the token is attached to the server's response. In this case, before you submit a POST request, you first read the response to your GET request from the server and the new token will be attached to it. Then you use it to generate new brute-force POST request. There may be ...


7

Yes: CSS can contain malware, though in my experience, its usually been tied to a vulnerability, e.g. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3971 As far as it containing JavaScript, that's certainly a vector, though successful exploitation should generally be limited by vulnerabilities within the Browser, the OS and the JavaScript engine. ...


7

An attacker can conduct a bruteforce attack using Burp Intruder, with an extender extension to handle the CSRF token. Adding a captcha to the login page doesn't solve the problem, it raises the bar by forcing the attacker to break the captcha cracking service at 1,000 solutions for $1. To answer your question, neither a captcha nor a CSRF token is ...


5

CSS rules can actually contain JS code (supported by at least some browsers), so from that perspective CSS can be "as bad as" JS. This SO answer might be helpful if you want more detail. http://stackoverflow.com/a/482088


4

Yes. This could solve your problem: mysyte.com/?token=xxx sets a cookie and redirects to mysite.com/changepwd without returning any markup mysite.com/changepwd recognises the user by the cookie and can safely request for 3rd party resources without leaking the token through referrer headers. To answer your second question: if the resource is over http, ...


4

Yes, there's a possible attack: You someday change the frontend, and stop using JSON and start using something else. The XSS stored on the database kicks in and your users are attacked. It is a very good practice to sanitize the user input as soon as possible. I always sanitize them as soon as it reaches my code.


4

Usaually the user's browser stores some cookies with a random string identifying the user on the server. More secure variants of this additionally check other parameters as the browser version, OS of the user and approximate location. Basically, if you visit a webpage like facebook with a cookie, you get authenticated only with the random string in the ...


4

A session id should be a Cookie parameter, and should never appear in the URL. Any value in the URL A will show up in the referer header, as well as access log files. A web application will end up transmitting authentication credentials to other websites, and storing them in plaintext on the filesystem. Additionally, when you pass a session id in the ...


3

It is safe. You have used SqlParameters so you don't need to worry about SQLi in this case. There are situations where using parameters might not protect you from SQLi, like using a parameter to construct dynamic SQL in a stored proc, but there isn't anything like that going on here. This is a textbook example of when parameterization prevents ...


2

CRSF attacks work by tricking a user (usually already logged in), into performing a request that servers the end of the attacker (either by getting him to click on a hyperlink, through a method such as XSS). An anti-CSRF token protects sensitive requests, by requiring an unpredictable value (provided to the user on an earlier page) to be sent as part of ...


2

The answer to this question has two sides... First: If you host the libraries yourself then you have to check the security notices on the library regularily and update the library accordingly. This can be a very time consuming task if you include several libraries which must be updated independently. On the other side you can audit each library you use. ...


2

This is not susceptible to SQL injection. This method incorporates the prototypical advice for avoiding SQL injection, which is to use parameterized queries. This explicitly separates the data in the arguments from the executable code.


2

Unfortunately your question is lacking some details, but I can give you some food for thought on this that will help put this in context. First of all there are different protocols that could be used for an attack such as ICMP, or UDP or TCP. Without knowing more about the target or type of traffic generated it's hard to truly predict what impact it would ...


2

The session is just a random generated token which is impractical to guess. There are many scenarios in which stealing sessions are possible such as Cross Site Scripting (XSS) or by sniffing the traffic if the attacker has access to a networkin node between client and server. To solve the XSS issue you need to not have validation issues. This means proper ...


2

Make the token single-use: expire it when the page is first requested, so it's no longer of any use to anyone after that point should leakage occur. You can also respond to the initial request with a redirect to a neutral URL which you don't mind being leaked (having set up a cookie/session to remember the authentication). However this still leaves the ...


2

According to the article a user created a user named "login_home_index_html" then they used HTML and CSS to hide stuff on their profile page and make it look like it was the legitimate login page. From what it looks like is MySpace didn't sanitize its user's custom HTML properly.


2

Due to the same-origin policy for cookies, a kind of "chicken or the egg" situation is created. In order for the attacker to make this XSS vector viable, they would need another flaw to set the cookie value . One possible exploit path is using a XSS vulnerability on a subdomain to leverage the following property of cookies: www.foo.bar.example.com ...


2

The Origin-inheritance rules for iframes will prevent malicious content within an iframe from accessing the DOM of the parent. Allowing sensitive control functional, like administrative pages to be placed within an iframe exposes you application to clickjacking. As a result most security-aware application disallow iframes with the x-frame-options. ...


1

First: you cannot be sure that the API key is private and will remain private. As soon as the device/product/application is on the real world, it can and will be broken. Don't rely on it. And as soon as the key leaks, nothing will stop anybody to simply start sending requests, and you can't tell who is sending, or how to filter or block fraudulent ...


1

Updated There are many variation on how you could implement what you have requested, they all have pros and cons so it really depends on your business requirements as to which is the best. Keychain: Prompt for group password and cache The least complicated way would be to ask the each user for the password and then cache the group password privately for ...


1

Is comparing the CSRF token on the cookie header with the form's hidden element be enough? A random token that has to be the same on the cookie and the form is a common anti-XSRF strategy, the ‘double-submit cookie’. It is used by, for example, Django, so clearly it is considered enough by some. It is, however, weaker than the generally-recommended (eg ...


1

Is not enough to validate CSRF tokens on the client, because you cannot know if the client is the user, or another site impersonating the user. You must compare the token sent by the user with the token you have stored on the server.


1

CSRF token need to be check on server side. That said, the token is often stored in a cookie so your approach is ok. CSRF work like that : For request : Create token and store in on server or in cookie Add the token to the form When you receive a post, verify that the token in the form is the same one as the token saved on server side (or cookie)


1

I'll have a shot at addressing this one. Is this acceptable, first of everything, from a security standard (i.e. accepting an unsigned software)? Accepting unsigned software that is trusted for some other reason in itself isn't an issue. Accepting ActiveX isn't considered acceptable at all. I'd suggest running the browser that uses ActiveX within its own ...


1

There are two different types of issues with untrusted data: It can contain malicious code to be executed directly (malware) It can be crafted in such a way that it will cause your legitimate applications to behave erratically (exploit) and perform something bad (payload) JavaScript really is in the first category. When browser or PDF writer vendors (or ...


1

This is a quite a broad question in that this could be (and has been) implemented in any of a large number of different ways. They generally involve storing a persistent cookie in the browser, and here are a few. The cookie might contain: An authentication token. (As Tokk described in his answer.) With state on the server (in the database, for instance) ...


1

The IP addresses seem to belong to a plethora pf european ISPs/data centers: inetnum: 83.31.0.0 - 83.31.255.255 netname: NEOSTRADA-ADSL descr: Neostrada Plus descr: Warszawa country: PL inetnum: 178.217.184.0 - 178.217.191.255 netname: HOSTEAM-1 descr: HOSTEAM S.C. country: PL ...


1

Ok, I figured it out. Since the application send local query to local database, in order to capture these queries I should capture lo packets with tcpdump: # tcpdump -xx -i lo This works perfectly.


1

By https-only I'm assuming you mean the HTTP Only flag, although it is accessed over HTTPS. The non HTTP Only cookies could be compromised if there are any XSS flaws on the website. The non secure flagged cookies could be compromised if the user was using a browser that does not support HSTS (such as Internet Explorer). This would be a MITM attack on a ...


1

You will get that error when you access Gmail, and there isn't really anything you can do about it, except to try different browsers. This is due to HSTS (HTTP Strict Transport Security) which Google has implemented along with the option to include certificate pinning. This means that in order to access their sites without this warning, you need not only ...



Only top voted, non community-wiki answers of a minimum length are eligible