OAuth 2.0 系列文目錄

https://blog.yorkxin.org/posts/2013/09/30/oauth2-1-introduction/

廣告

Web Security

HTTP Headers的資安議題:
http://devco.re/blog/2014/03/10/security-issues-of-http-headers-1/

防止CSRF攻擊:
http://blog.jdriven.com/2014/10/stateless-spring-security-part-1-stateless-csrf-protection/

幫Spring Security加上x-auth-token:
http://blog.jdriven.com/2014/10/stateless-spring-security-part-2-stateless-authentication/

弱點掃描軟體:
Burp Suite / N-Stalker / nessus

Authentication using certificates, Tomcat and Spring security

Use LDAPS for Spring Security:
http://l-lin.github.io/2014/09/09/Auth_with_certificates_Tomcat_spring/

– 顯示LDAPS certificate:
openssl s_client -showcerts -connect myserver:636
– 存成X509 certificate檔:
echo -n | openssl s_client -connect myserver:636 | sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ > myserver.crt

– 儲存certificate到JRE: (預設密碼:changeit)
keytool -import -keystore /opt/jdk7/jre/lib/security/cacerts -alias myserver -file myserver.crt
– 刪除certificate:
keytool -delete -alias myserver -keystore /opt/jdk7/jre/lib/security/cacerts -storepass changeit

– Client certificate over SSL
http://stackoverflow.com/questions/875467/java-client-certificates-over-https-ssl

-Djavax.net.ssl.keyStoreType=pkcs12
-Djavax.net.ssl.trustStoreType=jks
-Djavax.net.ssl.keyStore=clientcertificate.p12
-Djavax.net.ssl.trustStore=gridserver.keystore
-Djavax.net.debug=ssl # very verbose debug
-Djavax.net.ssl.keyStorePassword=$PASS
-Djavax.net.ssl.trustStorePassword=$PASS

top command explanation

top – 16:23:02 up 14 days, 23:08, 7 users, load average: 0.01, 0.04, 0.12
Tasks: 233 total, 1 running, 232 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.7 us, 0.3 sy, 0.0 ni, 98.6 id, 0.3 wa, 0.1 hi, 0.1 si, 0.0 st
KiB Mem: 16368856 total, 11506728 used, 4862128 free, 544236 buffers
KiB Swap: 8200188 total, 0 used, 8200188 free, 6060844 cached

a: PID — Process Id
The task’s unique process ID, which periodically wraps, though
never restarting at zero.

b: PPID — Parent Process Pid
The process ID of a task’s parent.

c: RUSER — Real User Name
The real user name of the task’s owner.

d: UID — User Id
The effective user ID of the task’s owner.

e: USER — User Name
The effective user name of the task’s owner.

f: GROUP — Group Name
The effective group name of the task’s owner.

g: TTY — Controlling Tty
The name of the controlling terminal. This is usually the
device (serial port, pty, etc.) from which the process was
started, and which it uses for input or output. However, a
task need not be associated with a terminal, in which case
you’ll see ‘?’ displayed.

h: PR — Priority
The priority of the task.

i: NI — Nice value
The nice value of the task. A negative nice value means higher
priority, whereas a positive nice value means lower priority.
Zero in this field simply means priority will not be adjusted
in determining a task’s dispatchability.

j: P — Last used CPU (SMP)
A number representing the last used processor. In a true SMP
environment this will likely change frequently since the kernel
intentionally uses weak affinity. Also, the very act of
running top may break this weak affinity and cause more
processes to change CPUs more often (because of the extra
demand for cpu time).

k: %CPU — CPU usage
The task’s share of the elapsed CPU time since the last screen
update, expressed as a percentage of total CPU time. In a true
SMP environment, if ‘Irix mode’ is Off, top will operate in
‘Solaris mode’ where a task’s cpu usage will be divided by the
total number of CPUs. You toggle ‘Irix/Solaris’ modes with the
‘I’ interactive command.

l: TIME — CPU Time
Total CPU time the task has used since it started. When
‘Cumulative mode’ is On, each process is listed with the cpu
time that it and its dead children has used. You toggle
‘Cumulative mode’ with ‘S’, which is a command-line option and
an interactive command. See the ‘S’ interactive command for
additional information regarding this mode.

m: TIME+ — CPU Time, hundredths
The same as ‘TIME’, but reflecting more granularity through
hundredths of a second.

n: %MEM — Memory usage (RES)
A task’s currently used share of available physical memory.

o: VIRT — Virtual Image (kb)
The total amount of virtual memory used by the task. It
includes all code, data and shared libraries plus pages that
have been swapped out and pages that have been mapped but not
used.

p: SWAP — Swapped size (kb)
Memory that is not resident but is present in a task. This is
memory that has been swapped out but could include additional
non-resident memory. This column is calculated by subtracting
physical memory from virtual memory.

q: RES — Resident size (kb)
The non-swapped physical memory a task has used.

r: CODE — Code size (kb)
The amount of virtual memory devoted to executable code, also
known as the ‘text resident set’ size or TRS.

s: DATA — Data+Stack size (kb)
The amount of virtual memory devoted to other than executable
code, also known as the ‘data resident set’ size or DRS.

t: SHR — Shared Mem size (kb)
The amount of shared memory used by a task. It simply reflects
memory that could be potentially shared with other processes.

u: nFLT — Page Fault count
The number of major page faults that have occurred for a task.
A page fault occurs when a process attempts to read from or
write to a virtual page that is not currently present in its
address space. A major page fault is when backing storage
access (such as a disk) is involved in making that page
available.

v: nDRT — Dirty Pages count
The number of pages that have been modified since they were
last written to disk. Dirty pages must be written to disk
before the corresponding physical memory location can be used
for some other virtual page.

w: S — Process Status
The status of the task which can be one of:
‘D’ = uninterruptible sleep
‘R’ = running
‘S’ = sleeping
‘T’ = traced or stopped
‘Z’ = zombie