Tag Info

New answers tagged

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

There is no reason that this should not work as long as third party cookies are enabled in your browser. HTML form POSTs can be used, or in the case that the forms are a multi-stage process then this will be more useful to run as XHR requests as your attacking page can then control the requests and issue them in turn - just as your are doing. Make sure ...


1

Of the two choices, checking the domain is probably better not for technical reasons, but for social reasons: you (probably) don't want some users to be "more equal" than others. Can you start with a short list of approved domains and pend for approval attempts that aren't on the list? That gives you a chance to build up your "approved" list relatively ...


1

Unless they have some form of bug bounty type program, you are putting yourself at risk by disclosing to organizations that haven’t hired you. The organization can turn around and say “You’re hacking us, this is proof. We’re suing you.” I have had to fight senior leadership at past jobs to not take that course of action. Or similar minded BS because they see ...


0

The error message you got is because the Cross-origin resource sharing (CORS) is not enabled on the server you try to attack. So all your AJAX requests will not be accepted by the server that host the web services. So if you enable CORS on your target server, the server will accept your AJAX requests. Do not use AJAX since if CORS is not enabled your ...


0

Try catching the error with nothing. The SOP error does raise an exception, which does stop your script execution. If you instead Catch the error, the request will be fired away, your response will be filtered, a exception is thrown that will catched, and your script will continue with the next request. So basically, now it works like this: attackstep1() ...


0

Take a look at the chrome developer console. It will tell you why the action is failing (should come up as an error). Are you setting any headers on your AJAX? SOP restricts what headers you can set and the browser will fall over while trying to do that if you don't respect SOP.


0

Here is what to do: Using an anonymous email(i.e https://anonymousspeech.com), Send them this message -one by one-: "Hi, If these are the credentials you are using for your admin panel (username/password), then you should change it immediately!"


0

Once the injection is present, one does not need to 'click on the link.' In the example provided, should the HTML + JavaScript be rendered, then the alert() code will run automatically - without user interaction. This works in both examples - regardless of where the XSS is located in the HTTP session. All that is necessary is that the XSS is redirected ...


0

Cookies set over HTTP are presented over HTTPS. If an attacker has full control of a victim's network traffic, they can set a cookie over HTTP, and this will cause an XSS attack against the HTTPS site. I believe that HSTS would stop this, although I haven't confirmed myself.


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 ...


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 ...


1

Possibly, yes. In many typical configurations, where servers have not had extensive security hardening, it would be possible. Factors that might permit this: The application server would naturally require a network path to the database server, therefore any firewall would be configured to allow connections. The application server is likely, in a typical ...


1

Leveraging other specialty tools to help you verify reported or potential vulnerabilities can help a lot. For example, using tools like XSS Validator to actually confirm JS execution. For SQLi, I will often fire up multiple copies of SQLmap to test the different reported SQLi vectors while I work on other tasks. There is probably no way to avoid manual ...


1

I personally see a lot of false positives with Cross Site Request Forgery. This may not be the answer you're looking for, but you need to verify them to the best of your ability. If you find something is beyond your ability you have a couple options: learn how to do it - this of course takes time and experience, a luxury we don't always have lean on a ...


1

Anyone who is watching network traffic on my web app can see the token (in headers) and can copy it and form their own malicious calls. That is correct. This is why you would want to make sure you use a secure connection (HTTPS in the URL), which will prevent man in the middle attacks.


1

I don't think they spoofed the domain name. I would say they either compromised the server or found some sort of HTML injection vulnerability that allowed them to just drop in the HTML that they wanted onto a "legitimate" myspace page that existed on their domain.


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.


0

If you don't want to share keys AND you use asymmetric keys then you can key each server separately and have each server set a different iss (issuer) claim. Then the recipient of the JWT can "look up" the appropriate public key based on the iss claim. Our lookup was basically a config file that mapped the iss value to a file system location of the public ...


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 ...


0

How about sending the information the the local server and then using a back-end technology (PHP?) to send it to the 3rd party server? Your browser is preventing this as a security measure (AJAX Call to a 3rd party server)


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)


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.


-1

Addslashes you will fall in the all mighty encoding... Its basicly a skill war in terms the one that knows more.... Thruth is we say it like that because its sopose to make ppl like you do what your doing unfortunatly in the incorrect place lol. Since the point is to you to learn how to write decent code and not just copy a recepie i will leave some hints, ...


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 ...


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 ...


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, ...


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 ...


0

Perhaps you are being hack via man in the middle? Scan for mac adresses on your network. With cain and abel you can see who is on it, and then if they are on it, you can report it to the feds.


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 ...


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 credentials are never stored either at the user end or at the server end(if configured as per security standards). If you want to keep your session active for a long time, or make sure your password is remembered next time when you login, then the browser communicates with the server to generate a random set of data that is stored in the form of Cookies. ...


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 ...


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. ...


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 ...


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


0

In MySQL: SET GLOBAL general_log = 'ON'; With following Query you can check, where the data is logged, and if the logging is enabled: SHOW VARIABLES LIKE '%general_log%';


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 ...


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.


0

You can use Jet Profiler for catch your querys and is a cross-platform program and you can download a free version.


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 ...


0

If you want to intercept SSL traffic, you'll need to install the burp CA cert. See the burp docs for details.


1

The scheme you describe is commonly used to ensure that a link is current, so if someone's changed the content, no other references to it will continue to work. Generating a new GUID upon reboot guards against someone making database changes while the server is down, ensuring old links are invalidated. This scheme has almost nothing to do with security, ...


1

The best you could do is use a ssh connection to work on those files. If that is not an option you should try to make it possible. If ssh is really not possible you should check the following: use https with a valid certificate (without that password will be send as plain text!) your .htaccess uses a strong password (otherwise it might be brute forced) ...


0

Locking someone out after wrongfully entering their info for x amount of times for x hours/days is a good idea, but annoying to users, this helps preventing Bruteforcing. What could be an alternative, is that instead of getting a list when you enter a SSN number, that you have to manually enter the address yourself, and a script checking if that address is ...


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.



Top 50 recent answers are included